cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
729
Visitas
0
ÚTIL
0
Comentarios
Cisco Moderador
Community Manager
Community Manager

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!

Ir al foro de Discusión
 


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)


Pregunta: Que tal saludos a todos; debido a que esto es un route dinámico y OMP es el encargado de levantar las VPN ¿esto garantiza el ruteo síncrono en ambos sentidos entre los sitios de un cliente por ejemplo? - Josué R. (min.20)

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.

Pregunta: gracias - Josué R. (min.24)

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.

Pregunta: Estos usan el vector distancia o son rutas que aprenden los Túneles? - Josué R. (min.26)

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.

Pregunta: ¿En la Conformación del transporte, cuando el equipo está detrás de un NAT, puedo variar el puerto de origen para salir con la misma IP pública, pero de esta forma tener NAT full connect? - Gabriel U. (min.27)

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 

Pregunta: Puedo habilitar en un mismo lugar físico 2 cEdge en distintos site id anunciando el mismo segmento LAN ? (considerando que son la misma sucursal) ¿se pierde alguna propiedad? - Alfredo Ch. (min.30)

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 

Pregunta: ¿Dónde es mejor el filtro de rutas, en el controlador o el cEdge en la redistribución de OMP al Protocolo de servicio? - Gabriel U. (min.34)

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 

Pregunta: Hola buenas tardes a todos. Cuáles son los timers de los updates de OMP ? - René C. (min.41)

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.

Pregunta: Para service-chaining si el FW no va conectado directo al EDGE XIOS-XE se podría formar un túnel GRE hasta dónde reside el FW? - Carlos Alan M. (min.47)

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.

Pregunta: En este tipo de Topologías que es lo más recomendable y eficiente trabajar Hub and Spoke o Full Mesh? - Jorge V. (min.51)

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.

Pregunta: Hola, sí todos mis enlaces en los Edges son privados cómo levanto el tráfico de control con el validator/manager y controller si está en el Cloud de Cisco? - Manuel Fernando R. (min.53)

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 

Pregunta: Sí, la restricciones son que un lado debe ser nat full connect, pero mi pregunta es si puedo usar la misma IP de origen, variando el puerto de origen para obtener un NAT full connect? - Gabriel U. (min.55)

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.

Pregunta: Cuál es el valor recomendado de ecmp-limit ? considerando que impacta en la tabla de ruteo por vpn - Alfredo Ch. (min.59)

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.

Pregunta: ¿En caso de la pérdida de comunicación contra los controladores en la nube de Cisco, es buena práctica tener otro controlador on-premise? - Gabriel U. (min.61)

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.

Pregunta: En caso de pérdida de las conexiones de control, qué comando me permite ver el tiempo que queda para que se cumpla el gracefull-restart? - René C. (min.61)

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 

Pregunta: Buenos días, para las sesiones BFD, en un escenario de 2 transportes, es necesario que ambos tengan conexiones de control para que estos estén arriba?, me ha sucedido que si el edge por un transporte no tiene alcance a los controladores pero tiene habilitado crear tuneles de controll, no se forman los túneles BFD. - Carlos Alan M. (min.62)

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.

Pregunta: Gracias, sí, la configuración la entiendo. Pero en el caso que se configuro el gracefullrestart al máximo de 7 días, y por problemas de acceso a internet se pierden las conexiones de control. Cómo sé cuánto tiempo le queda al cedge antes de perder la información recibida por OMP ? - René C. (min.89)

Respuesta (Kassandra H.): No hay un comando que nos de el tiempo restante.

Pregunta: No tiene el lab en yaml ? - Gustavo M. (min.98)

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

iaestrad.jpgIan 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.

ericgar.jpgEric 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.

kasherna.jpgKassandra 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.

 

Para obtener más información, visite los contenidos de la sección de Routing y Switching.
Si usted tiene dudas o está experimentando problemas técnicos con alguno de los productos Cisco, publique su pregunta, solicite información o utilice el motor de búsqueda de la Comunidad de Cisco en español, antes de abrir un caso con el TAC.
Vamos a comenzar

¡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: