07-27-2023 12:47 AM - editado 08-25-2023 11:15 AM
Presentación del webinar Community Live
Con la colaboración de Yosef García y Antonio Pérez
¿Cómo funciona la integración? ¿Qué recomiendan nuestros expertos?
Descubre la respuesta a las preguntas de nuestra audiencia al final de este documento.
Este webinar trata sobre la integración entre la infraestructura de red del centro de datos existente y la Infraestructura centrada en aplicaciones de Cisco (Cisco ACI) con un enfoque en la conectividad de Capa 2 y Capa 3 entre ambas redes. Incluye mejores prácticas para evitar problemas durante la integración y con las funcionalidades que ofrece ACI en un entorno ya integrado.
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!
¿Cómo enviar una nueva 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&R 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 (Yosef G.): Nos encontramos trabajando internamente en un documento que permita explicar con mayor detalle la diferencia, desafortunadamente por el momento no tenemos ningún documento oficial que se pueda consultar.
Respuesta (Alejandro A.): En Network Centric, un EPG debe estar asociado a un BD y un BD a un VRF, es la forma tradicional que se hacían las redes, lo que llamamos un mapeo 1 a 1. Entonces sí, un BD solo puede estar a un VRF.
Respuesta (Alejandro A.): Es necesario siempre tener las relaciones correctas entre las políticas, esto asegura la integridad de funcionamiento de ACI. En ACI tenemos un modelo de objetos que es la base de cómo funciona ACI y si la relación de objetos no existe podemos esperar comportamientos no esperados.
Respuesta (Alejandro A.): Este tipo de recomendaciones van a ser especificas a la necesidad de cada cliente, generalmente es común tener esta políticas habilitadas en ACI, pero como menciono es en base a cada necesidad. ACI depende de estas políticas en algunas implementaciones de algunos features.
Respuesta (Alejandro A.): La lógica de tener muchos VRFs en Application Centric o Network Centric se va a mantener de la misma forma, que quiero decir con esto: En Network Centric todo es un mapeo 1 a 1, es decir un VRF a uno o muchos BDs y un BD un EPG. En Application Centric la lógica cambia pero sólo a nivel de BD-EPG, la lógica sería, un VRF a uno o muchos BDs y un BD a muchos EPGs, como puedes ver donde cambia es en realmente en la parte de BD y EPGs, pero lo de VRF se mantiene igual.
Respuesta (Alejandro A.): (en espera)
Respuesta (Alejandro A.): Sí se puede, pero las mejores prácticas nos dicen que tengamos estos vlan pools separados para cada dominio, esto debido a que por ejemplo para VMM debemos colocar un Allocation tipo Dinámico y para Phy deberían de ser Allocation tipo Estático, hay escenarios muy específicos donde pueden convivir pero se tiene que revisar la justificación y operabilidad de manera detallada.
Respuesta (Alejandro A.): Cisco ISE es un producto que generalmente sirve para temas de seguridad donde vas a tener los servicios de TACACS para AAA y otras funciones. Cisco ACI es una solución para Data Centers que puede brindar conectividad a gran escala y gran capacidad de envío de tráfico por sus link de 40-100Gb; además ACI brinda soluciones de End to End con temas de integración para soluciones de Virtualización! Punto clave, ACI es una solución de data center y ISE es un producto de seguridad.
Respuesta (Alejandro A.): Puedes definir a que leaf le vas a asignar a cada BD, esto pasa básicamente de forma automática cuando asignas un puerto dentro de un EPG. Automáticamente el leaf configura el BD relacionado al EPG cuando se cumple esta configuración. Esto para que la utilización de recursos sea más efectiva en ACI.
Respuesta (Alejandro A.): Hernán, cuando haces una asignación de un puerto de forma estática dentro de un EPG, ACI te da la opción de configurar el puerto de manera truncal, incluyendo la vlan nativa y de modo acceso. Esto se realiza dentro del Tenant > Application Profile > EPG > Static Ports.
Respuesta (Alejandro A.): Sí, esto debido a que ACI es una solución SDN donde toda su configuración la envía un controlador llamado APIC, toda la configuración se hace desde este controlador.
Respuesta (Alejandro A.): Hay muchas cosas a considerar, para que pueda funcionar ACI vas a depender de si ya tengas las controladoras que son mandatorias para poder implementar ACI. No es como que puedas llegar y simplemente convertir tus equipos a ACI y listo, hay consideraciones a tomar. Es necesario una estrategia en tu caso para asegurarnos que la migración para de forma correcta.
Respuesta (Yosef G.): Para hacer uso de ACI se cuenta con un sistema de licenciamiento conocido como smart licensing, las licencias van a depender del número y modelos de dispositivos que se requieran integrar a la fábrica. Puedes consultar más sobre los detalles del licenciamiento en el siguiente enlace: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/guide-c07-736255.html#4CiscoACItieredlicensing
Respuesta (Alejandro A.): Ya viene en camino, eso te lo puedo asegurar. Ya está programando sólo es cuestión de tiempo.
Respuesta (Alejandro A.): Puedes hacerlo sin problema, el Application Profile es nuestra forma de agrupar EPGs, pero no significa que necesariamente todos los EPGs estén dentro del mismo BD o VRF.
Respuesta (Alejandro A.): Quiero entender que esto te refieres a compartir prefijos mediante algún Routing Protocol, si es así ACI tiene algo que se llama L3Out que es justo para poder anunciar estas redes que existen en ACI o para redistribuir rutas que se aprenden de algún otro componente de red. En los siguientes Slides ya van a mostrar esta parte.
Respuesta (Alejandro A.): ACI tiene da acceso a sus APIs, es muy común monitoreo o automatización de configuración por sus APIs.
Respuesta (Alejandro A.): ACI por defecto lo que hace es simplemente reenviar los BDPUs, pero no los procesa. ACI se podría ver afectado si recibe un TCN de STP porque va este si causa una acción de borrar las tablas de MAC/EP en el BD donde este el puerto que reciba el BDPUs. La mejores prácticas dicen que mejor evitar este tipo de escenarios y hacer que la topología de STP no dependa de ACI y para esto bloqueamos el envío de BPDUs a ACI.
Respuesta (Alejandro A.): ACI tiene una solución para esto que se llama ACI Multisite, esto para lograr extender los 2 Data Centers Geográficamente separados controlado desde un punto central. https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739609.html
Respuesta (Alejandro A.): En el L3Out siempre es necesario definir nuestro External EPG, es la relación directa a los objetos dentro de ACI, entonces es necesario poner los prefijos en esta parte para que podamos completar la relación de objetos de ACI correctamente. Generalmente lo que sea hace es un 0.0.0.0 que cubra todos los prefijos para no tener que colocar cada uno de los prefijos que se aprenden por OSPF, pero es importante mencionar que hay diferentes escenarios que esto se puede manejar de forma diferente.
Respuesta (Alejandro A.): Esto depende de la configuración de Flooding que tengas en el BD.
Respuesta (Alejandro A.): Te enviaremos la información.
Respuesta (Jimena S.): Se mandó un correo electrónico con las respuestas a las preguntas concretas.
Respuesta (Yosef G.): Nos hemos intentado comunicar contigo para darle seguimiento a tu pregunta y poder proporcionar la información que requieres.
Nuestros expertos
Yosef García - Se unió a Cisco en 2021 y es Technical Consulting Engineer del Centro de Asistencia Técnica (TAC) de Cisco para Data Center ACI. Yosef participa continuamente en proyectos enfocados en la detección de errores y la creación de contenido especializado para ACI. Anteriormente ha trabajado como ingeniero de verificación y validación de nuevas soluciones para diferentes sectores de telecomunicaciones. Yosef tiene las certificaciones CCNP Enterprise, CCNP Data Center y DevNet.
Antonio Pérez - Se incorporó a Cisco a finales de 2021 y es Technical Consulting Engineer del Cisco TAC para Data Center ACI. Cuenta con más de una década de experiencia como ingeniero de redes enfocándose principalmente en protocolos de enrutamiento a nivel Enterprise y Service Provider; así como en la integración de diferentes proveedores de comunicaciones celulares GSM, GPRS y LTE. Ha estado involucrado en proyectos de seguridad y migración de centros de datos, incluidas las mejores prácticas para instalar y montar equipos de red. Antonio tiene certificación CCNP Enterprise, CCNP Data Center (core exam) y CompTIA N+ y se está preparando para tomar su examen DevNet Associate.
¡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