Cisco 300-410: Políticas, Escalabilidad y Selección de Rutas de BGP — Guía de estudio

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Forma parte de la Cisco CCNP Enterprise 300-410 ENARSI — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Cisco, o realiza tests cronometrados en ExamRoll.io.

Descripción general

El Border Gateway Protocol (BGP) gobierna la política de enrutamiento entre dominios y la distribución escalable de la alcanzabilidad. El diseño de sesiones resilientes, la comprensión del comportamiento del siguiente salto y de las actualizaciones, y la aplicación de políticas con pleno conocimiento del algoritmo de mejor ruta son fundamentales. A gran escala, iBGP se basa en route reflectors o confederaciones, mientras que herramientas avanzadas como el anuncio condicional, la originación de ruta por defecto, multipath y el dampening refinan el comportamiento. Esta sección detalla las mecánicas operativas, los compromisos de diseño y los modos de fallo que debe anticipar, y proporciona un enfoque sistemático de resolución de problemas tanto para prefijos faltantes como para la selección de rutas inesperadas.

Diseño de sesiones y establecimiento de vecinos

• Adyacencia eBGP vs. iBGP
  • Los peers eBGP están en ASNs diferentes y por defecto usan un TTL de 1, lo que requiere una adyacencia de un solo salto a menos que se configure de otra manera.
  • Los peers iBGP están en el mismo ASN y requieren una malla completa o una alternativa de escalado (route reflectors o confederaciones). iBGP usa un TTL de 255, y las sesiones frecuentemente usan interfaces loopback para mayor estabilidad.
• Alcanzabilidad TCP y la FSM de BGP
  • BGP se ejecuta sobre el puerto TCP 179; la formación de la sesión depende de la alcanzabilidad genérica IP/TCP y de la máquina de estados finitos (FSM) de BGP (Idle → Connect/Active → OpenSent → OpenConfirm → Established).
  • Impedimentos comunes: ACLs/firewalls en el puerto TCP/179, Control-Plane Policing (CoPP) que limita la tasa de BGP, y enrutamiento asimétrico que interrumpe TCP.
  • Verificación práctica:

undefined

; si está inestable (‘flapping’), inspeccione

undefined

para validar CoPP. Durante la validación de la política, establezca las acciones de conform/exceed en ’transmit’ para evitar descartes no deseados.

• Autenticación y fortalecimiento del TTL
  • La autenticación MD5 (

undefined

) protege contra sesiones falsificadas; las discrepancias mantienen la sesión en estado Active.

• La seguridad GTSM/TTL (

undefined

) mitiga los ataques basados en la CPU; no la combine con

undefined

en el mismo vecino.

• Peering con loopbacks, update-source y multihop

  • El peering de loopback a loopback es más resiliente a los fallos de interfaz; requiere una originación única y una extensión del TTL:

undefined

-

undefined

• Asegure la alcanzabilidad unicast a las loopbacks mediante rutas estáticas o un IGP. La falta de recursión hacia la loopback impide silenciosamente el establecimiento de la sesión.
• Procesamiento del siguiente salto y next-hop-self
  • Por defecto, eBGP establece el siguiente salto a la dirección del vecino que anuncia la ruta.
  • Por defecto, iBGP no cambia el siguiente salto; los routers de borde deben configurar

undefined

en iBGP para evitar agujeros negros de siguiente salto de terceros. -

undefined

undefined

Procesamiento del siguiente salto y selección de la mejor ruta

Selección de la mejor ruta de BGP en plataformas Cisco (de mayor a menor importancia):

1. Weight (solo Cisco, local al router; se prefiere el más alto). Por defecto: 32768 para rutas inyectadas localmente, 0 en otros casos.
2. Local Preference (dentro del AS; se prefiere el más alto). Por defecto 100; se propaga en iBGP.
3. Originada localmente (network/aggregate/redistribute) preferida sobre aprendida.
4. Longitud del AS-path (se prefiere el más corto). El ‘prepending’ aumenta la distancia percibida.
5. Código de origen (IGP < EGP < Incomplete).
6. MED (se prefiere el más bajo). Se compara solo entre rutas del mismo AS vecino, a menos que

undefined

esté habilitado;

undefined

asegura una comparación de MED consistente entre peers. 7) Preferir eBGP sobre iBGP. 8) Métrica IGP más baja hacia el siguiente salto de BGP (hot-potato). 9) Preferir la ruta más antigua para reducir la inestabilidad (‘churn’) (si está habilitado, sujeto a dampening/multipath). 10) Criterios de desempate: longitud mínima de la cluster-list, el originator-ID más bajo, el router-ID de BGP del vecino más bajo y, finalmente, la dirección IP del vecino más baja.

Notas de diseño y errores comunes:

• La alcanzabilidad del siguiente salto es fundamental. Una ruta puede ser la ganadora en BGP pero aun así fallar la recursión de CEF si el siguiente salto no está resuelto.
• Al anunciar rutas en iBGP después de aprenderlas por eBGP, no olvide configurar

undefined

; de lo contrario, los routers iBGP pueden ver un siguiente salto eBGP inalcanzable y descartar el tráfico.

• El MED a menudo se malinterpreta; sin

undefined

, el MED de diferentes ASes vecinos no se evaluará, lo que lleva a valores aparentemente “ignorados”.

Herramientas de políticas: Atributos, comunidades y filtrado

• Local Preference, Weight, AS-path prepending, MED
  • Prefiera un ISP de baja latencia aumentando el LOCAL_PREF para esas rutas (por ejemplo, set local-preference 200). Esto cambia la selección del tráfico de salida en todo el AS sin tocar el plano de datos IP.
  • Weight es solo local; úselo para preferencias específicas del router (neighbor 198.51.100.1 weight 50 o mediante un route-map con set weight).
  • El AS-path prepending (set as-path prepend 65000 65000 …) hace que una ruta sea menos atractiva para el tráfico de entrada a su AS al aumentar la distancia percibida. Aplíquelo de forma selectiva; su uso excesivo reduce la alcanzabilidad.
  • El MED (set metric) sugiere un punto de egreso hacia su AS a su vecino. Su efecto depende de la política del vecino.
• Política de comunidades
  • El envío de comunidades no es automático; actívelo con neighbor x send-community [both | extended].
  • Comunidades bien conocidas: no-export, no-advertise, internet, local-AS y no-export-subconfed (útil con confederaciones).
  • Las comunidades estándar son valores de 32 bits (formato AA:NN con ip bgp community new-format).
  • Las comunidades extendidas (64 bits) transportan semántica adicional (por ejemplo, route-targets en VPNv4).
  • Las comunidades grandes (96 bits, A:B:C) proporcionan escalabilidad y claridad en ASN de 4 bytes.
  • Ejemplo: hacer coincidir la comunidad y establecer atributos
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Filtrado de prefijos y de AS-path
  • ip prefix-list controla la granularidad de los NLRI; as-path access-list utiliza regex para restringir las rutas de AS. Ambos se aplican con route-maps o directamente con neighbor … prefix-list/as-path access-group.
  • Entrante vs. saliente:
    • El filtrado de entrada moldea lo que entra en su tabla BGP e influye en la selección de la mejor ruta.
    • El filtrado de salida controla lo que usted anuncia; un route-map de salida mal aplicado puede alterar inesperadamente los atributos en las rutas originadas localmente (por ejemplo, anteponer el AS local en todos los anuncios hace que los vecinos externos vean su prefijo a dos saltos de AS de distancia en lugar de uno). Restrinja siempre los route-maps con coincidencias explícitas.
  • Una política mínima y específica reduce la inestabilidad (churn) y evita los agujeros negros (blackholing). Incluya siempre un permit final en las prefix-lists para evitar denegaciones no deseadas.

Ejemplos de configuración cortos y específicos:

• Aumentar la Local Preference para las rutas del ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• AS-path prepend para un anuncio de salida específico:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Escalabilidad de iBGP y comportamientos avanzados

• Route reflectors (RRs)
  • Reemplazan la malla completa de iBGP designando RRs que reflejan rutas entre clientes y no clientes. Los bucles se previenen con los atributos originator-ID y cluster-list.
  • El Cluster ID por defecto es el router ID del RR; cuando existen múltiples RRs, use Cluster IDs únicos para prevenir bucles persistentes y mejorar la diversidad de rutas.
  • Desventajas: los RRs pueden causar una selección de rutas subóptima (ocultamiento de rutas). Se mitiga con la ubicación de los clientes, clústeres diversos, add-path y ajustando los parámetros de bestpath.
• Confederaciones
  • Particionan un AS grande en sub-AS que se comunican con eBGP internamente pero aparecen como un único AS externamente.
  • Ventajas: reduce la malla iBGP y el radio de impacto de las políticas; Desventajas: complejidad operativa y posibles sutilezas con MED/next-hop a través de las fronteras de los sub-AS.
• Anuncio condicional y rutas por defecto

  • El anuncio condicional le permite anunciar una ruta solo cuando otra ruta está ausente/presente.

undefined

• Originación de ruta por defecto:
  • neighbor 198.51.100.1 default-originate [route-map RM] anuncia 0.0.0.0/0 sin importar si la tiene en la RIB (con RM controlando las condiciones). Alternativamente, network 0.0.0.0 requiere una ruta coincidente en la RIB.
• Multipath
  • Reparte la carga a través de múltiples rutas BGP de igual costo con maximum-paths [ebgp|ibgp] n. Use bgp bestpath as-path multipath-relax para permitir multipath en eBGP a través de diferentes AS-paths bajo condiciones controladas. En L3VPNs de MPLS, maximum-paths ibgp n habilita ECMP de PE a PE.
• Recursión de rutas y fallos de RIB
  • BGP instala una ruta solo si el siguiente salto puede recurrir a una entrada de reenvío válida y ninguna ruta con una distancia administrativa menor ya posee el prefijo.
  • Causas comunes de fallo en la RIB:
    • Existe una ruta con mejor AD (conectada/estática/IGP).
    • Siguiente salto no resuelto (no hay ruta IGP/estática hacia el siguiente salto).
    • Hay presente una ruta más larga y específica (el tráfico coincide con la más específica).
  • Comprobaciones útiles: show ip bgp <prefix>, show ip bgp rib-failure, show ip route [vrf NAME] <prefix>, y búsquedas en CEF para validar la recursión.
• Dampening
  • bgp dampening penaliza los prefijos inestables (“flapping”) y los suprime hasta que se estabilizan. Parámetros: half-life, reuse, suppress, max-suppress-time.
  • Desventajas: puede ocultar una recuperación legítima y ralentizar la convergencia. Aplíquelo de forma restringida en los bordes inestables y evite aplicar “dampening” a la alcanzabilidad del núcleo o al espacio crítico del cliente.

Resolución sistemática de problemas (prefijos faltantes y rutas incorrectas):

1. Verificar el estado de la sesión BGP: show ip bgp summary; si es inestable (“flapping”), inspeccione CoPP y la alcanzabilidad de TCP/179.
2. Confirmar la admisión por política: show ip bgp neighbors x received-routes/advertised-routes; asegúrese de usar “soft-reconfiguration” o “route refresh” cuando sea necesario.
3. Validar el siguiente salto: show ip bgp <prefix> y show ip route [vrf NAME] <next-hop>; corrija el IGP/recursión antes de ajustar los atributos.
4. Revisar filtros: prefix-lists, as-path access-lists y communities; confirme que el vecino tenga send-community.
5. Inspeccionar atributos: weight/local-pref/AS-path/origin/MED; habilite deterministic-med o always-compare-med donde sea apropiado.
6. Examinar fallos de RIB y especificidad: una ruta conectada/estática/IGP con una AD más baja o una ruta más específica anulará a BGP.
7. Confirmar mecanismos de escalabilidad: en los RRs, vigile el ocultamiento de rutas y los bucles de cluster-list; en las confederaciones, valide el uso de no-export-subconfed.

Escenario de un problema práctico

Acme Manufacturing opera el AS 65010 con dos ISPs: ISP-A (baja latencia) e ISP-B (de respaldo). Acme utiliza iBGP entre tres routers de núcleo con dos route reflectors y anuncia 203.0.113.0/24. Después de añadir un route-map de salida en el borde con ISP-B, los sitios remotos reportan un aumento de la latencia y algunas rutas prefieren ISP-B inesperadamente.

Enfoque:

1. Confirmar el estado de la sesión y las políticas

   • show ip bgp summary y show policy-map control-plane para asegurar que no haya inestabilidad (“flaps”) en BGP debido a CoPP. Justificación: un plano de control inestable produce cambios constantes que enmascaran los efectos de las políticas.

2. Verificar la alcanzabilidad del siguiente salto

   • show ip bgp 203.0.113.0/24 y show ip route <next-hop>. Justificación: la recursión del siguiente salto debe tener éxito para que los atributos importen.

3. Inspeccionar la política de salida en ISP-B

   • show run | sec router bgp; revise neighbor … route-map OUT out. Justificación: los route-maps amplios pueden modificar inadvertidamente todos los prefijos anunciados, incluidos los originados localmente.

4. Restringir el AS-path prepending a los NLRI objetivo

undefined

Justificación: la coincidencia específica limita el “prepending” al prefijo deseado y evita alterar los atributos de otros anuncios. El permit 20 explícito asegura que las rutas que no coinciden no sean descartadas.

5. Preferir ISP-A globalmente para el tráfico de salida

undefined

Justificación: LOCAL_PREF influye en la elección de egreso en todo el AS (más alto es mejor) y es el mecanismo más limpio para preferir el ISP de baja latencia.

6. Asegurar que las “communities” propaguen el comportamiento deseado

undefined

Justificación: el etiquetado (“tagging”) permite tomar decisiones de política “downstream” (por ejemplo, preferencia basada en el RR) y requiere send-community para su propagación.

7. Validar el comportamiento del RR y evitar el ocultamiento de rutas

   • En ambos RRs, confirme que los cluster-ids sean únicos y las asignaciones de clientes; habilite bgp additional-paths send receive select best 2 donde sea soportado. Justificación: en un entorno con múltiples salidas, los RRs pueden ocultar una ruta mejor. El uso de “additional-paths” o una topología de clientes cuidadosa reduce la suboptimalidad.

8. Verificar los resultados y el estado de instalación

   • show ip bgp 203.0.113.0/24 para confirmar weight/local-pref/AS-path/MED; confirme la selección de eBGP sobre iBGP y la métrica del IGP hacia el siguiente salto.
   • show ip bgp rib-failure para asegurar que la ruta elegida se instale en la RIB. Justificación: confirma que tanto el plano de control como el de datos reflejan el diseño previsto.

Esta secuencia corrige los cambios no deseados en el AS-path (asegurando que los AS externos vean el prefijo de Acme a la distancia deseada), impone la preferencia por ISP-A a través de LOCAL_PREF, preserva la visibilidad de la política con “communities”, y valida el siguiente salto y la instalación para que el reenvío final coincida con el diseño.

← Diseño · Todos los dominios · Redistribución de Rutas y Enrutamiento Basado en Políticas →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →