custom.ribbon_feed
cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
1327
Visitas
1
ÚTIL
0
Comentarios
Cisco Moderador
Community Manager
Community Manager

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!

Ir al foro de Discusión

 


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


Pregunta: Solamente el vPC funciona en switches Nexus o funciona en alguna otra familia de switches Cisco? - Marco M. (min.11)

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.

Pregunta: Puedo asociar el vPC desde un Nexus a switches catalyst 9000 que solo utilizan Etherchannel? tienen un lab sobre eso? - Percy V. (min.13)

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.

Pregunta: Puedo crear un vpc con dos nexus del mismo modelo pero diferente generación? por ejemplo un 93180YC-FX y un 93180YC-FX3P o tienen que ser mismo modelo y misma generación? - Oscar P. (min.14)

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.

Pregunta: Buenos dias por favor una consulta puedo formar un vPC de un solo enlace? y cual es la consideracion o recomendaciones para formar vPC? los enlaces tienen que ser pares? - Luis B. (min.16)

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.

Pregunta: Por que no hay loops en VPC ? - Santiago M. (min.20)

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.

Pregunta: Si eso lo tenia entendido pero sería bueno que lo hagan en un laboratorio de muestra y enfatizar que solo funciona con LACP y no con PAgP ? - Percy V. (min.20)

Respuesta (Emmanuel F.): Hola Percy, al final de la sesión habrá un laboratorio demo.

Pregunta: Como queda HSRP ? - Gustavo M. (min.20)

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.

Pregunta: ¿en que casos empleas las VLAN no-vPC? - Edwin L. (min.21)

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

Pregunta: ¿por que debes configurar cada vPC peers por separado? ¿cuando se podra manejar un solo plano de control para que solo debas configurar una sola vez? - Edwin L. (min.24)

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.

Pregunta: En caso de falla de algun switch, el standby pasa como pasa como active de forma automatica. Y que sucede cuando regresa el que era active? toma el roll que tenia nuevamente? - Erik H. (min.27)

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.

Pregunta: ¿que nos puedes comentar en relacion a la imolementacion de Capa 3 en un esquema de vPC? ¿que aspectos debemos considerar? - Edwin L. (min.28)

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.

Pregunta: cuando hay falla tipica en Peer keep -alive y el peer-link, es decir, seria falla fisica o algun otro detalle? - Santiago M. (min.29)

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

Pregunta: Asimismo he visto en algunas experiencias que falla mucho la conexción etherchannel entre un Switch Nexus/catalyst con un servidor, especialmente cuando usa LACP, han tenido casos asi en redes en producción? - Percy V. (min.33)

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.

Pregunta: Siempre dicen el problema es el sistema operativo, pero obvio que no siempre es así, hay incompatibilidad entre equipos cisco y servidores en Linux/windows server? o en su hardware? - Percy V. (min.36)

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.

Pregunta: Estos VPC son solo para nexus devices? - Carlos R. (min.37)

Respuesta (Emmanuel F.): Hola Carlos, si, es únicamente para Nexus switches.

Pregunta: Desde que version de NXOS y que modelo, se puede configurar el preempt? - Alan M. (min.38)

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.

Pregunta: comentan que peer-switch solo se recomienda en el vpc que será el root de la red, por ejemplo, el vpc de Core, por lo que no es necesario ponerlo en los vpc de acceso/distribución, correcto? en caso de que esos vpc de acceso/distribución tengan el peer-switch activado, existe algún comportamiento anormal en la red? - Oscar P. (min.39)

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.

Pregunta: Hola team para este escenario de VPC Layer 3, ¿Para un neighbor con EIGRP u OSPF entre los vPC peers que es lo recomendable habilitar, una conexión de capa 3 entre los VPCs peers formando el neighbor por ese link y colocar las SVIs en passive para evitar neighbors entre las SVI a nivel VPC peers por el peer-link, o colocar las SVI en passive y solo dejar una SVI que establezca el neighbor entre VPC peers vía el peer-link? - Lucio G. (min.42)

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.

Pregunta: Que pasaria si ese link dedicado implementado en versiones inferiores a la 7.1 se emplearon ips publicas para esas conexiones punto a punto? - Mariluz S. (min.43)

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.

Pregunta: El tema es el STP que produce cierta incompatibilidad, algunos lo desactivan, pero aún asi el Port-channel no funciona adecuadamente, sería bueno un lab con switch nexus y servidor linux/windows server configurado adecuadamente y sería realmente viral ya que no hay en internet sobre eso? - Percy V. (min.45)

Respuesta (Emmanuel F.): Hola Percy, gracias por el feedback, lo tomaremos en cuenta para nuestras próximas sesiones/publicaciones.

Pregunta: hola! Que pasaria si ese link dedicado para conexiones L3 entre 2 vpc domain diferentes, como en el ejemplo, se implemento en versiones inferiores a la 7.1 se emplearon ips publicas para esas conexiones punto a punto? - Mariluz S. (min.50)

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.

Pregunta: Ya que en ACI no se ocupa un keepalive fisico y aparte ACI lo configura, hay algun issue conocido para el keepalive? - Luis C. (min.61)

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.

Pregunta: Eso deberían de soportar en su CML, ya que a veces se presenta bugs, con equipos reales si resulta pero como saben no podemos hacer labs en una red en produccion? - Percy V. (min.73)

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.

Pregunta: pero si uno no sabia eso, y lo utilizo, por ejemplo 4.4.4.1/30 que problemas se podrian presentar? - Mariluz S. (min.74)

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.

Pregunta: y si en vez de utilizar ospf utilzo eigrp? - Alexis P. (min.78)

Respuesta (Emmanuel F.): Layer3 peer-router nos permite utilizar EIGRP, OSPF, BGP indistintamente, nos permite utiizar el peer-link para formar la adjacencia.

Pregunta: puedo pasar protocolor de ruteo a traves del peerlink? - Alexis P. (min.89)

Respuesta (Emmanuel F.): si, es posible utilizando el feature "layer3 peer-router" bajo el dominio de vPC.

Pregunta en el Chat: Puedo tener vpc son más de dos Nexus? - Javier A. (min.11)

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.

Pregunta en el Chat: que modelo de dispositivos estas utilizando en el lab ? 9K ? - Javier A. (min.48)

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.

Pregunta en el Chat: Qué modelo específico de los 9k ? - Javier A. (min.51)

Respuesta (Sergio G.): 93180YC.

Pregunta en el Chat: Gracias Osmar, entonces el Hsrp debe estar obligatoriamente en el L3? - Javier A. (min.78)

Respuesta (Osmar R.): Asi es, HSRP se configura en las Interface VLANs de L3 que tengamos en los VPC Peers.


Nuestros expertos

jgandari.jpgJuan 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.


osresend.jpgOsmar 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.

 
Para obtener más información, visite los foros de discusión de Data Center en la sección de Data Center.
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: