08-17-2023 06:51 AM - editado 09-01-2023 11:37 AM
Presentación del webinar Community Live
Con la colaboración de Juan Carlos Gandaria y Osmar Reséndiz
Esta sesión lo ayudará a comprender más acerca de vPC (virtual Port-Channel) , la configuración básica de vPC y cómo hacer troubleshooting en escenarios o situaciones comunes con vPC.
vPC permite que dos interfaces físicas conectadas a dos switches Cisco Nexus aparezcan conectadas como un solo port-channel a un solo equipo, lo que brinda beneficios de redundancia, así como la simplificación de spanning-tree.
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 (Emmanuel F.): Hola Marco, la solución de vPC esta diseñada para Nexus switches, existen conceptos similares en otras tecnologías como VSS en Catalyst, pero vPC es exclusivo de Nexus.
Respuesta (Emmanuel F.): Hola Percy, la comunicación entre Nexus corriendo vPC y Catalyst es posible, de lado de los Nexus ambos hablan VPC utilizando LACP, y de lado de los Catalyst es transparente y se comunican utilizando LACP como un portchannel tradicional.
Respuesta (Emmanuel F.): Hola Oscar, la solución esta pensada para tener ambos Nexus utilizando la misma versión de hardware y de software, no esta soportado tener dieferentes linecards.
Respuesta (Emmanuel F.): Hola Luis, la idea de esta solución es hacer un bundle de interfaces para tener redundancia, puede estar un solo link activo pero se pierde el objetivo principal, que es tener ambos Nexus activos enviando tráfico, le recomendación es tener un link para el keep-alive como link de capa 3, un portchannel entre ellos como peer-link, y 2 o más links conectados a otro dispositivo funcionando como un vPc link.
Respuesta (Emmanuel F.): Hola Santiago, debido a que ambos switches funcionan como un solo dispositivo desde la perspectiva de capa 2, todos los links quedan activos y evitamos bloqueos por spanning-tree.
Respuesta (Emmanuel F.): Hola Percy, al final de la sesión habrá un laboratorio demo.
Respuesta (Emmanuel F.): Hola Gustavo, HSRP puede coexistir con vPC, el requerimiento es habilitar el feature "peer-gateway" bajo el dominio de vPC para permitir que cualquiera de los dos Nexus responda a nombre de su peer independientemente de que Nexus reciba el tráfico.
Respuesta (Emmanuel F.): Hola Edwin, en vPC es necesario que la configuración de spanning-tree sea la misma en ambos Nexus para las vPC vlans, regularmente utilizamos non-vPC vlans cuando se require que las vlans configuraciones de spanning-tree no sean las mismas en ambos switches, por ejemplo, en el escenario en el que se requiera que otro dispositivo en la red sea el root de STP..
Respuesta (Emmanuel F.): Hola Edwin, la configuración es por separado debido a que nos conectamos a cada Nexus utilizando un CLI individual, existen soluciones como DCNM que nos permiten hacer un push de la configuración a más de un dispositivo simultaneamente.
Respuesta (Emmanuel F.): Hola Erik, en caso de falla, ya sea de el primary o el secondary, el Nexus que queda vivo asume el rol de Active, una vez que regresa el Nexus que falló, este asume el rol de stand-by ya que por default los Nexus no son "preempt" para evitar cambio de role innecesario, sin emavrgo esta funcionalidad puede ser habilitada manualmente para que al regresar el Nexus de falla tome el rol de activo nuevamente.
Respuesta (Emmanuel F.): Hola Edwin, vPC es un protocolo de capa 2, por lo cual la mayoría de las consideraciones en configuración se hacen a nivel de capa 2, sin embargo, se recomienda tener consistencia en la SVIs creadas en ambos vCP peers, las SVIs que se crean de un lado deben estar creadas en el otro peer.
Respuesta (Emmanuel F.): Hola Santiago, las fallas típicas son principalmente por reachability, es decir que un peer no ve al otro ya sea por falla física, configuración, inconsistencias, spanning-tree, entre otros..
Respuesta (Emmanuel F.): Hola Percy, las principales fallas de interoperabilidad entre estos equipos se deben a configuración o cableado, sin embargo, ambos son completamente compatibles debido al standar de LACP.
Respuesta (Emmanuel F.): Hola Percy, la interoperabilidad entre Nexus vPC y servidores puede configurarse con "mode active" (LACP) ó "mode on" siempre alineados a el standar 802.3ad y pensados para interactuar con cualquier vendor que siga el standar.
Respuesta (Emmanuel F.): Hola Carlos, si, es únicamente para Nexus switches.
Respuesta (Emmanuel F.): Hola Alan, vpc role preempt esta disponible en la familia de Nexus 3000 y 9000 en las versiones 7.X, 9.X y 10.X.
Respuesta (Emmanuel F.): Hola Oscar, si, "peer-switch" esta pensado para ser utilizado únicamente en un par de Nexus vPC que serán root de spanning-tree en la red, configurarlo en más de un dominio de vPC en la misma red puede ocasionar problemas con STP.
Respuesta (Emmanuel F.): Hola Lucio, en este escenario se recomienda utilizar el feature "layer3 peer-router" bajo el dominio de vPC que nos permitirá levantar una adjacencia de cualquier protocolo de ruteo dinamico utilizando el peer-link entre los Nexus, de esta manera ambas SVI´s estarán enviando tráfico activamente y se formarán adjacencias entre ellos y entre los dispositivos conectados a los Nexus vPC peers.
Respuesta (Emmanuel F.): Hola Mariluz, se recomienda utilizar direccionamiento privado bajo estas configuraciones ya que es un link dedicado exclusivamente a enviar "keep-alives" entre los Nexus peers, sin embargo, al ser una conexión punto a punto bajo una VRF exclusiva de keep-alive no debería ocasionar ningún problema.
Respuesta (Emmanuel F.): Hola Percy, gracias por el feedback, lo tomaremos en cuenta para nuestras próximas sesiones/publicaciones.
Respuesta (Emmanuel F.): Hola Mariluz, se recomienda utilizar direccionamiento privado bajo estas configuraciones ya que es un link dedicado exclusivamente a enviar "keep-alives" entre los Nexus peers,este tráfico no necesita salir a internet, sin embargo, al ser una conexión punto a punto bajo una VRF exclusiva de los keep-alives, no debería ocasionar ningún problema.
Respuesta (Emmanuel F.): Hola Luis, el problema más común es que los keep-alive mesages no sean recibidos o entregados a su destino, esto puede ser ocasionado debido a problemas de capa 1 ó problemas de configuración, se recomienda para este link siempre utilizar un link dedicado de capa 3 o hacerlo sobre la interfaz de management, en algunos utilizan el puerto de management conectado a un switch de administración, pero esto introduce un punto de falla adicional ya que en caso de que este switch falle, se perderán los keep-alive.
Respuesta (Emmanuel F.): Gracias por tu feedback Percy, correcto, CML nos permite hacer una aproximación a las redes en producción, sin embargo, siempre es recomendado emular todo en dispotivos fisicos ya que en un ambiente en producción no solo interviene el software si no también el hardware.
Respuesta (Emmanuel F.): Hola Mariluz, si el keep-alive esta configurado exclusivamente en una VRF dedicada para esta función, no hay ningún problema.
Respuesta (Emmanuel F.): Layer3 peer-router nos permite utilizar EIGRP, OSPF, BGP indistintamente, nos permite utiizar el peer-link para formar la adjacencia.
Respuesta (Emmanuel F.): si, es posible utilizando el feature "layer3 peer-router" bajo el dominio de vPC.
Respuesta (Emmanuel F.): Hola Javier, un vPC domain consta de 2 Nexus switches, existe compatibilidad entre más de un vPC domain, sin embargo este deberá tener otro domain ID ya que solo son 2 switches por dominio.
Respuesta (Osmar R.): Los modelos del lab son Nexus 9K para los VPC Peers y un par de Nexus 3K para los hosts. Los Nexus 3K no estan en VPC.
Respuesta (Sergio G.): 93180YC.
Respuesta (Osmar R.): Asi es, HSRP se configura en las Interface VLANs de L3 que tengamos en los VPC Peers.
Nuestros expertos
Juan Carlos Gandaria - Escalation Engineer en el equipo de Data Center Routing and Switching (DCRS) dentro del Centro de Asistencia Técnica (TAC) global de Cisco que brinda soporte técnico. Con cinco años de experiencia en DCRS, participando principalmente en el crecimiento técnico del equipo de DCRS West Coast, Juan colabora con capacitación y documentación técnica.
Osmar Reséndiz - Technical Consulting Engineer en el equipo de Data Center Routing and Switching (DCRS) dentro del TAC Global. Titulado como Ingeniero en Comunicaciones y Electrónica, y actualmente está certificado en CCNA, CCNP Routing & Switching y DevNet.
¡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