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

Presentación del webinar Community Live

Inmersión profunda al Enrutamiento Basado en Políticas (PBR)

Con la colaboración de Adriana Ríos Suárez y Antonio Pérez Oseguera.

En el ámbito de las redes informáticas modernas, el Enrutamiento Basado en Políticas o "Policy Based Routing" (PBR por sus siglas en inglés) es una técnica esencial para la gestión del tráfico de datos.

ACI de Cisco utiliza PBR para dirigir y optimizar el flujo de paquetes en la red, basándose en políticas definidas que atienden los requisitos específicos de las aplicaciones. En esta sesión platicamos un poco sobre su funcionamiento y configuración, así como la prevención, la detección y la corrección de errores comunes.

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 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: En una topología PBR con un Load Balancer conectado en One Arm, ¿es posible asignar direcciones VIP en el LB de un segmento de red distinto al que se usa en el Bridge Domain para la interconexión entre el Leaf y el LB? Si es factible, ¿cómo aprende el Leaf las direcciones VIP, a través de GARP enviados por el LB? - Óscar S. (min.22)

Respuesta (Wilfrido S.): Hola Oscar, gracias por tu pregunta, dado que necesitamos que el Bridge Domain en ACI sea el gateway del dispositivo L4-L7, en nuestro caso el Load Balancer, es necesario que el mismo tenga asignada una IP dentro de la subnet definida en el BD en ACI, esto con el motivo que también se aprenda como un endpoint en la fábrica para hacer el redireccionamiento.

Pregunta: En caso de falla la redirección puede tener condiciones para estos casos de balanceo? - Wilmer A. (min.28)

Respuesta (Jeepson R.): ¡Hola Wilmer, muchas gracias por tu pregunta! ¿Te refieres a falla en ACI y/o en el dispositivo L4-L7 y tener una ruta de backup?

Pregunta: Buen día, ¿qué pasa si el FW al que redireccionamos soporta MTU de 1500, mientras que la comunicación entre EPGS utiliza MTU 9000?, ¿se verán afectadas las transacciones que antes usaban jumbo frames? - Santiago I. (min.29)

Respuesta (Wilfrido S.): Hola Santiago, gracias por tu pregunta. Es correcto que en contraste con las redes tradicionales, en ACI se trabaja con MTU 9000, sin embargo al ser interfaces de acceso para el FW se puede modificar este MTU para hacer match con lo que se tiene en el FW, sin embargo sí se vería afectado los jumbo frames dado que estamos poniendo el link en 1500, para mayo información te recomiendo validar el White Paper que tiene Cisco para PBR, saludos!

Pregunta: ¿Es posible conectar físicamente un nodo PBR en modo One-Arm a través de un vPC, es decir, una interfaz a leaf-1 y otra interfaz a leaf-2, ambas interfaces como parte de un vPC? De ser posible, si se habilita PBR node tracking usando ICMP como keepalive, se asume que "ambos leaves enviarán Keepalives" hacia el nodo PBR conectado por vPC, es correcto este assumption? - Óscar S. (min.65)

Respuesta (Jeepson R.): ¡Hola Oscar, muchas gracias por tu pregunta! 1. Sí, es posible conectar un nodo PBR en modo One-Arm a través de un vPC en ACI. 2. Si se habilita el PBR node tracking con ICMP keepalives, ambos leaves enviarán estos keepalives hacia el nodo PBR conectado por el vPC.

Pregunta: Tengo un par de dudas fuera del escenario que se ha presentado, como ejemplo ¿Es válido utilizar PBR Threshold en un Service Graph con un solo PBR node, con la finalidad de aprovechar la acción de bypass cuando se detecta una falla en dicho nodo PBR? - Óscar S. (min.59)

Respuesta (Jeepson R.): ¡Hola Oscar, muchas gracias por tu pregunta! Sí, es válido utilizar PBR Threshold en un Service Graph con un solo nodo PBR en Cisco ACI para aprovechar la acción de bypass cuando se detecta una falla en dicho nodo PBR. El PBR Threshold te permite configurar un umbral de fallos, y si se supera este umbral (por ejemplo, si el nodo PBR no responde a los keepalives de ICMP), el tráfico puede ser redirigido o bypassed, es decir, el tráfico puede fluir directamente entre los endpoints sin pasar por el nodo PBR.

Pregunta: Por último, en topologías PBR con un solo L1 device, ¿tiene sentido agrupar las interfaces "Out/In" del L1 device en un Health Group para evitar un black-hole? La pregunta deriva del PBR tracking L2 ping que se usa en este escenario, en donde el L1 solo permite el L2 ping que se está realizando entre los leaf switches que conectan al L1 device (en otras palabras, el L1 device no procesa activamente el L2 ping). - Óscar S. (min.65)

Respuesta (Wilfrido S.): Hola Óscar, gracias por tu pregunta. Es una pregunta muy interesante, recordando que la opción de Health Group se utiliza para prevenir el black-hole de tráfico cuando se tiene un conector del PBR ya sea consumer o provider en down, normalmente esto se habilita en el L4-L7 Device, si no se puede disponible esta feature se hace uso de los Health groups, ahora regresando a la pregunta depende del diseño de la red, si agrupamos el L1 device en un solo Health Group si las interfaces están down genera blackhole.

Pregunta: Hola, el contract_parser ya está cargado en los Nexus Leaf o hay que cargarlo previo al uso? Si no está cargado, cuál es el procedimiento? - Nicolás R. (min.85)

Respuesta (Jeepson R.): ¡Hola Nicolás, muchas gracias por tu pregunta! Si está ejecutando versión 3.2 o posterior, el script (contract_parser.py) está disponible directamente en los controladores APIC y leaf switches. En resumen, el contract_parser debería estar cargado y operando como parte del software de ACI. No es común que necesites cargarlo manualmente. Si encuentras problemas, la verificación del estado y la actualización del software son pasos iniciales recomendados.

Pregunta: ¿En qué casos es recomendable utilizar contrato vzany para el pbr? - Guillermo G. (min.93)

Respuesta (Wilfrido S.): Hola Guillermo, gracias por tu pregunta. Primero he de indicar que esta opción solo está disponible en versiones 3.2 en adelante. Como se comentó en la presentación, depende del diseño de la red, pero generalmente se configura cuando se realiza el redireccionamiento de muchos EPGs a muchos EPGs.

Pregunta: Entonces, apar vzany de acuerdo con lo mencionado respecto que los filtros no deben estar en common, en el common no pueden colocarse l4 -L7 shared? o bien solo el filtro debe estar fuera? - Marcelo P. (min.102)

Respuesta (Wilfrido S.): Esta pregunta fue respondida en vivo (ver el final de la grabación).

Pregunta PQ#1: ¿Cuáles son los modelos de despliegue para un PBR?

Opciones de respuesta: a) GoTo, GoThrough, 1-arm y 2-arm b) routed, bridged, 1-arm, 2-arm c) managed, unmanaged, routed, not-routed // Respuesta Correcta: a) GoTo, GoThrough, 1-arm y 2-arm

Pregunta PQ#2: ¿En qué componente de configuración se definen las IPs y MACs del PBR?

Opciones de respuesta: a) Service Graph Template b) L4-L7 Policy Based Redirect c) L4-L7 Device // Respuesta Correcta: b) L4-L7 Policy Based Redirect

Pregunta PQ#3: ¿Cuál es el leaf responsable de aplicar la política de redirección si el leaf de ingreso no conoce el endpoint?

Opciones de respuesta: a) El leaf destino b) El leaf de ingreso c) Los spines mediante COOP // Respuesta Correcta: a) El leaf destino


Nuestros expertos

ariossua.jpgAdriana Ríos Suárez es Ingeniera en Telemática egresada del Instituto Politécnico Nacional. Se unió a Cisco en 2021 como Technical Consulting Engineer para Data Center ACI. Cuenta con más de una década de experiencia en administración de sistemas operativos y software, así como en redes de Data Center. Ha participado en Cisco Live Las Vegas 2023 y 2024, así como en diversas iniciativas de Innovación y Automatización. Adriana cuenta con las certificaciones CCNA, y RHCSA y RHCE por parte de Redhat, y se prepara para las certificaciones de DevNet Associate y ACI Specialist. 

aperezos.jpgAntonio 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, ACI Specialist, DevNet Associate, CompTIA N+ y se está preparando para tomar su examen ACI Advanced Specialist. 
 

Para obtener más información, visite los contenidos de 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: