el 02-20-2024 06:02 AM - fecha de última edición 03-04-2024 11:07 PM por Jimena Saez
Presentación del webinar Community Live
Con la colaboración de Ian Estrada, Eric García Guzmán y Kassandra Hernández.
¿Qué es el Overlay Management Protocol (OMP)? ¡Si quieren saber más no se pierdan este webinar!
Las redes de datos se transforman y simplifican con un enfoque definido por software. Se mejoran el rendimiento, la disponibilidad y la experiencia del usuario para lograr una mayor productividad. Los expertos en soluciones de Software-Defined Wide Area Network (SD-WAN) de Cisco, lo guiarán a través de los protocolos de enrutamiento y su funcionamiento en la solución de SD-WAN. Se explicará el uso de políticas centralizadas para una fácil orquestación de rutas en la red, lo que ayuda a tener un mejor control del plano de datos, haciendo la red más eficiente, segura y escalable entre todos los nodos de la red. Se presentará una demostración que ejemplificará cómo las políticas aplicadas a un controlador de enrutamiento conducen a una solución que puede manipular las rutas del plano de datos para el tráfico desde muy específico hasta muy general, dándole el tratamiento necesario para sus necesidades comerciales.
Recuerde que la presentación está disponible en pdf para su comodidad. Si este documento le ha resultado útil, no olvide calificar esta publicación con un voto de utilidad para validar su relevancia. ¡Muchas gracias!
Otros webinars relacionados a este tema que le sugerimos consultar:
¿Qué es SD-WAN? La solución de Red Definida por Software (Aug'23)
Políticas Localizadas de SD-WAN (Nov'23)
¿Cómo enviar una pregunta?
Ponemos a su disposición nuestro evento Ask Me Anything (AMA) en cuyo foro podrán externar dudas y solicitar apoyo de nuestros expertos en casos específicos de los temas abordados. ¡Esperamos sus preguntas!
Lista de las Q&A del webinar Community Live
Encuentre la lista de preguntas formuladas durante el seminario web Community Live de nuestro evento. Cualquier duda que no haya sido respondida durante la sesión será resuelta posteriormente aquí o en el foro de "Preguntas".
Lista de Preguntas y Respuestas (Q&A)
Respuesta (Kassandra H.): Hola Josué. Para las vpn de servicio, cada usuario crea las que necesita; las vpn disponibles para servicio son 1-511 y 513-65528.
Respuesta (Kassandra H.): Sin importar cuantas se creen, el vSmart creará tantas tablas de ruteo y los dispositivos podrán comunicarse entre ellos en ambos sentidos.
Respuesta (Kassandra H.): Lo que sucede es: los dispositivos envían sus rutas, el vSmart dependiendo de las políticas hace el compute, y envía el resultado de la tabla de ruteo a los dispositivos.
Respuesta (Kassandra H.): Una vez que los dispositivos lo conocen, crean túneles entre ellos y se comunican ya sin la necesidad de pasar por el controller.
Respuesta (Kassandra H.): No es distance vector, el protocolo de omp es algo similar a bgp, utiliza los TLOC para crear túneles entre los dispositivos, estos dispositivos todo el tiempo advierten el liveness y si se detecta que esta caído, el advertisement sucede. El orden en que sucede es: los dispositivos advierten sus TLOC al controller, el controller crea la tabla de ruteo y advierte a los demás edges, una vez que los edges conocen los tlocs de sus remotos, pueden formar túneles ipsec que serán como un point to point.
Respuesta (Kassandra H.): Sí es posible tener a los dispositivos detrás de un NAT device, para ello solo hay que tener en cuenta las restricciones del tipo de NAT que SDWAN soporta, los puertos privados de el TLOC no cambian, los puertos públicos dependerán del NAT device, la información viajara a través del tunnel ipsec, es decir lo que venga de la LAN, será encapsulado por IPSEC y enviado a través del overlay, entonces los únicos puertos que van a cambiar son los públicos de los TLOCS, para más información acerca de los puertos.
Respuesta (Kassandra H.): Te comparto el siguiente link https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/sdwan-xe-gs-book/cisco-sd-wan-overlay-network-bringup.html
Respuesta (Kassandra H.): Sí es posible, sin embargo para evitar un loop debes especificar cuál de los dos dispositivos tendrá una preferencia mayor de su tloc o al advertir su ruta, si no se hace correctamente esto puede causar un loop o incluso podría causar asimetric routing issues. Cuando son de una misma sucursal lo mejor y un diseño que sí es usado sería que sean de el mismo sitio y así se ahorra bandwidth incluso ya que al ser del mismo sitio no forman un túnel, y balancean el tráfico entre ambos.
Respuesta (Kassandra H.): Para más información acerca de dual sites, te comparto el siguiente link https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html
Respuesta (Kassandra H.): El controlador es como un route reflector, los dispositivos siempre advertirán al controllador todos sus TLOC, y todas sus rutas, a menos que se genere una política (la cual se configura en el controller) y el controler las filtre ya sea cuando las recibe o cuando las adviertes a los demás sitios, en el lado de los edges, solo se podrían filtran rutas por medio de ACL antes de advertir a OMP.
Respuesta (Kassandra H.): Para más información te comparto el link de centralized policies https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/policies/vedge-20-x/policies-book/centralized-policy.html
Respuesta (Kassandra H.): End of rib 300 seg holdtime 60 segundos, advertisement 1 sec para más información acerca del rango de timers te comparto el siguiente enlace https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_timers_7662.xml, una disculpa lo había respondido en otra pregunta.
Respuesta (Kassandra H.): Service chaining se define por medio de rutas de servicio, en mi experiencia como TAC no lo he visto combinado, sin embargo igual en lugar de configurar service chaining, se puede configurar un Túnel a un FW en específico, puede ser un thrid party tunnel o un SIG tunnel a umbrella, Zscaler u otro proveedor.
Respuesta (Kassandra H.): Esto depende totalmente de los requerimientos del cliente, el hub and spoke el beneficio que da es el control de cantidad de rutas y túneles creados además de evita consumo excesivo de bandwith.
Respuesta (Kassandra H.): Al menos uno de esos proveedores debe dar acceso a internet para formar Control connections con los controladores, y puedan tener un peering con el vsmart, si el perring no se forma no hay manera de advertir las rutas, una vez que al menos un túnel con el vsmart es creado se pueden levantar otros TLOCS que llevaran el comando max-control-connections 0, y este segundo TLOC podrá advertir sus rutas, no formará control connections pero sí formará túneles de DATOS entre los edges.
Respuesta (Kassandra H.): para más información te comparto el siguiente link https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_max_control_connections_7369.xml
Respuesta (Kassandra H.): Es posible sí, eso es usado para devices en un mismo sitio, sin embargo los túneles de datos pueden verse afectados dependiendo del tipo de nat utilizado, para ver el tipo de combinaciones de nat que permiten la creación de túneles de datos (bfd sessions) te comparto el siguiente link, https://www.cisco.com/c/en/us/support/docs/routers/sd-wan/214510-troubleshoot-bidirectional-forwarding-de.html.
Respuesta (Kassandra H.): El valor por defecto de rutas ECMP es 4, ese valor se puede modificar hasta 128, el modificarlo para la redundancia depende completamente de los requerimientos del cliente https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#Cisco_Command_Page.dita_baaf57ae-7989-42ba-9581-608487d85e9d pero debe tomarse en cuenta que un valor muy grande puede crear un overload en el controller ya que eso sucederá para todas y cada una de las rutas que los dispositivos envíen.
Respuesta (Kassandra H.): Sí, para tener high availability en un ambiente de producción, de mínimo se tienen dos controllers, de esta manera si los dispositivos pierden comunicacion con un controllers, el otro puede seguir manteniendo la tabla de ruteo, y en el peor de los casos si ambos controllers se pierden conexiones, aún existe otra característica que mantiene arriba los túneles de datos de los dispositivos por un tiempo de gracia, eso se configura por medio del comando graceful-restart.
Respuesta (Kassandra H.): el tiempo por defecto son 12 hours, no hay un comando que permita ver el tiempo restante. Para más información acerca de graceful restart les comparto el siguiente enlace https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/config-cmd.html#r_graceful_restart_3833.xml
Respuesta (Kassandra H.): El segundo link puede no tener control conexiones con los controllers, esto se logra con el max-control-connections 0 sin embargo, hay que tomar en cuenta que dependerá que el primer link siempre mantenga una sesión activa con el controllers y en caso de perder esa comunicación, después del tiempo de gracia, ambos TLOCS perderán sus túneles de datos ya que no habrá un túnel hacia los controllers que siga advirtiendo el liveness de esos TLOCS.
Respuesta (Kassandra H.): No hay un comando que nos de el tiempo restante.
Respuesta (Kassandra H.): No, este lab fue real. Desafortunadamente no tenemos laboratorios para compartir.
Respuesta (Ian E.): Hola Gustavo! Adjunto un documento donde explican muy bien lo que hicimos en el laboratorio, espero te sea de utilidad https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-book-xe/hub-and-spoke.html
Nuestros expertos
Ian Estrada es Ingeniero en Telecomunicaciones, Sistemas y Electrónica egresado de la Universidad Nacional Autónoma de México (UNAM). Se unió al programa de incubación de Cisco Academy en 2019 y luego se unió al equipo del Centro de Asistencia Técnica (TAC) de Cisco para la tecnología SD-WAN. Actualmente, Ian tiene cuatro años de experiencia en esta tecnología y desempeña el puesto de ingeniero de escalación de SD-WAN. Ha creado documentación y vídeos públicos de SD-WAN para Cisco.
Eric García es Ingeniero en Computación con especialidad en redes computacionales por la FES Aragón de la UNAM. Realizó una estancia profesional en el Instituto de Investigaciones en Matemáticas Aplicadas y Sistemas (IMASS) de la UNAM, y en la Dirección General de Computación y Tecnologías de la Información y Comunicación (DGTIC) de esta misma institución, en el área de Sistemas. Se unió a Cisco en 2016 y tiene más de cuatro años de experiencia en Arquitectura de Sistemas Operativos dentro del TAC de Cisco y tres años en SD-WAN. Eric ha creado documentación pública de SD-WAN para cisco.com y ha sido mentor de ingenieros dentro de TAC. Actualmente es ingeniero de escalación para TAC SD-WAN.
Kassandra Hernández es Ingeniera en Comunicaciones y Electrónica -con especialidad en Comunicaciones- del Instituto Politécnico Nacional (IPN) en México. Ella Ingresó al programa de incubadoras de Cisco Academy en 2019 y posteriormente se unió al equipo del TAC de Cisco para la tecnología SD-WAN. Actualmente cuenta con cuatro años de experiencia en esta tecnología y se desempeña como Team Captain de SD-WAN. Ha creado documentación y además es miembro del comité organizador de nuestros webinars Community Live para español.
¡Conecte con otros expertos de Cisco y del mundo! Encuentre soluciones a sus problemas técnicos o comerciales, y aprenda compartiendo experiencias.
Queremos que su experiencia sea grata, le compartimos algunos links que le ayudarán a familiarizarse con la Comunidad de Cisco:
Navegue y encuentre contenido personalizado de la comunidad