Dos problemas distintos, la misma herramienta — enviar el tráfico a un next hop específico según su origen o su aplicación, en lugar de lo que la tabla de enrutamiento elegiría por sí sola — coincidencia a nivel de interfaz por origen y por aplicación, una redirección a escala de red, comandos de verificación, y dónde termina el enrutamiento basado en políticas y dónde empieza route-policy.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
La tabla de enrutamiento responde a «cómo llego a este destino». El enrutamiento basado en políticas responde a una pregunta distinta: según quién lo pide y qué está pidiendo, por dónde debe ir realmente este tráfico en concreto.
Una tabla de enrutamiento normal toma una decisión por destino, y todo host que envíe a ese destino recibe la misma respuesta. Eso funciona bien hasta que deja de hacerlo — hasta que una fuente interna necesita una ruta específica sin importar lo que diga la tabla de enrutamiento sobre el destino, o una aplicación necesita su propia ruta por razones de latencia o costo mientras todo lo demás toma la ruta predeterminada. El enrutamiento basado en políticas (PBR) existe precisamente para esta brecha: primero hace coincidir el tráfico — por dirección de origen, protocolo, puerto, cualquier cosa que un clasificador de tráfico pueda expresar — y solo entonces decide el next hop, por delante e independientemente de la propia decisión de la tabla de enrutamiento.
A continuación, dos configuraciones concretas: hacer coincidir el tráfico en una única interfaz de entrada por dirección de origen y por aplicación (HTTP), cada una redirigida a un next hop distinto; y una política a escala de red que redirige el tráfico de un par origen-destino a un router específico, sin importar lo que elegiría por su cuenta la tabla de enrutamiento normal — construida aquí por OSPF. Si su escenario se parece más a enviar el tráfico de cada enlace de internet por su propio enlace con conmutación por error automática, eso es un problema relacionado pero distinto — vea nuestra nota de configuración de conmutación por error en doble WAN y reparto de carga para eso.
Un router, varias interfaces, y dos reglas de coincidencia independientes que deciden qué paquetes se redirigen antes de que la tabla de enrutamiento los vea siquiera.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Clasificadores de tráfico y destinos de redirección
| Coincidencia | Next hop de redirección | Precedencia |
|---|---|---|
| ACL 3005 — source 10.2.1.1/32 | 10.5.1.2 | 5 — evaluado primero |
| ACL 3006 — destination-port www (HTTP) | 10.3.1.2 | 10 |
| Unmatched traffic | 10.4.1.2 | Tabla de enrutamiento normal — preferencia de ruta estática 40 |
Cinco pasos: definir la coincidencia, emparejarla con una redirección, vincular todo en una sola política con precedencia, aplicarla a la interfaz y dirección correctas, y asegurarse de que el tráfico no coincidente aún tenga adónde ir.
#
sysname Router
#
acl number 3005
rule 0 permit ip source 10.2.1.1 0
#
acl number 3006
rule 0 permit tcp destination-port eq www
#
traffic classifier 10.2.1.1 operator or
if-match acl 3005
traffic classifier www operator or
if-match acl 3006
#
traffic behavior 10.2.1.1
redirect ip-nexthop 10.5.1.2
traffic behavior www
redirect ip-nexthop 10.3.1.2
#
traffic policy pbr
classifier 10.2.1.1 behavior 10.2.1.1 precedence 5
classifier www behavior www precedence 10
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
traffic-policy pbr inbound
#
interface GigabitEthernet2/0/1
ip address 10.3.1.1 255.255.255.0
#
interface GigabitEthernet2/0/2
ip address 10.4.1.1 255.255.255.0
#
interface GigabitEthernet2/0/3
ip address 10.5.1.1 255.255.255.0
#
ip route-static 192.168.1.0 24 10.3.1.2
ip route-static 192.168.1.0 24 10.4.1.2 preference 40
ip route-static 192.168.1.0 24 10.5.1.2
#
returnTres rutas estáticas llegan deliberadamente al mismo prefijo 192.168.1.0/24 — 10.4.1.2 lleva la preferencia más baja (40), por lo que gana la propia selección de la tabla de enrutamiento para el tráfico no coincidente, mientras que 10.3.1.2 y 10.5.1.2 permanecen alcanzables solo para que los next hops redirigidos por PBR sean válidos.
Una red distinta y más grande ilustra esto a mayor escala: RouterA, RouterB y RouterC comparten rutas mediante OSPF, y la tabla de enrutamiento por sí sola enviaría el tráfico de 10.0.2.0/24 a 10.0.0.0/24 vía RouterC. Una política de tráfico en RouterA redirige ese único flujo hacia RouterB en su lugar.
#
acl number 3001
rule 5 permit ip source 10.0.2.0 0.0.0.255 destination 10.0.0.0 0.0.0.255
#
traffic classifier rdt operator or
if-match acl 3001
#
traffic behavior rdt
redirect ip-nexthop 10.181.10.2
#
traffic policy rdt
classifier rdt behavior rdt
#
interface GigabitEthernet1/0/0
ip address 10.181.20.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.181.10.1 255.255.255.0
#
interface GigabitEthernet3/0/0
ip address 10.0.2.1 255.255.255.0
traffic-policy rdt inbound
#
ospf 1
area 0.0.0.0
network 10.0.2.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.181.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.10.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.181.10.0 0.0.0.255
network 10.184.10.0 0.0.0.255
#
return#
interface GigabitEthernet1/0/0
ip address 10.181.20.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.184.10.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.184.10.0 0.0.0.255
network 10.181.20.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
returnA pesar del nombre similar, route-policy es un mecanismo completamente distinto que opera en un plano diferente. Route-policy (configurada con route-policy ... permit/deny node ...) filtra y modifica las rutas mismas a medida que se aprenden o anuncian entre protocolos de enrutamiento — por ejemplo, aplicando un atributo local-preference o community a rutas BGP, o controlando qué rutas se redistribuyen de un protocolo a otro. El enrutamiento basado en políticas, en cambio, nunca toca la tabla de enrutamiento ni las rutas que contiene — intercepta paquetes que ya llegaron a una interfaz y los reenvía a un next hop específico según un clasificador de tráfico, sin importar lo que diga la tabla de enrutamiento. Una route-policy cambia qué rutas existen y cómo se etiquetan; una política de tráfico con PBR cambia adónde van realmente paquetes ya decididos. Un detalle que vale la pena tomar prestado de la configuración de route-policy: una route-policy necesita un nodo permit explícito y vacío al final, o las rutas que no coincidieron con ningún nodo anterior se filtran silenciosamente — un modo de fallo distinto del propio comportamiento de PBR ante tráfico no coincidente, pero un instinto similar a comprobar.
Verifique el clasificador, el comportamiento y la política de forma independiente, y luego confirme con una traza que el tráfico realmente sale por el next hop redirigido.
<Host> tracert -a 10.0.2.1 10.0.0.1
1 10.181.20.1 3 ms 2 ms 1 ms
2 10.181.10.2 4 ms 3 ms 3 ms
3 10.184.10.1 5 ms 4 ms 4 ms
4 10.0.0.1 6 ms 5 ms 5 msEl segundo salto (10.181.10.2) es la dirección de RouterB — confirmando que la política de tráfico redirigió este flujo allí en lugar de por la ruta preferida por OSPF a través de RouterC. Sus propias direcciones de salto y tiempos serán distintos; lo que importa es por qué router pasa la traza.
Las que convierten una redirección funcional en tráfico que silenciosamente va por el camino equivocado, o a ningún lado.
SÍNTOMAEl tráfico que claramente no coincide con ningún clasificador de la política termina siendo descartado o mal enrutado, en lugar de simplemente seguir la tabla de enrutamiento normal.
CAUSAAplicar traffic-policy en sentido entrante en una interfaz no crea una denegación por defecto como sí lo hace cierta lógica de ACL — pero si la ruta normal de la interfaz hacia ese destino está a su vez ausente o es incorrecta, no hay nada razonable a lo que el tráfico no coincidente pueda recurrir. PBR solo decide para lo que coincide explícitamente; todo lo demás necesita de entrada una entrada de tabla de enrutamiento funcional.
SOLUCIÓNConfirme la accesibilidad normal (una ruta en display ip routing-table) hacia el destino antes de superponer PBR — PBR reemplaza el next hop del tráfico coincidente, no crea accesibilidad de la nada.
SÍNTOMAExiste una ruta estática hacia la dirección del next hop de redirección, pero display ip routing-table muestra una ruta completamente distinta ganando para ese mismo prefijo.
CAUSAredirect ip-nexthop reenvía directamente los paquetes coincidentes a esa dirección — no exige que la ruta de esa dirección sea la mejor ruta propia de la tabla de enrutamiento. En la configuración de trabajo aquí, tres rutas estáticas al mismo prefijo coexisten deliberadamente: una gana la propia selección de la tabla de enrutamiento (valor de preferencia más bajo) para el tráfico no coincidente, mientras que las otras dos existen únicamente para que los next hops redirigidos por PBR sean alcanzables.
SOLUCIÓNNo suponga que el next hop de redirección necesita «ganar» ninguna comparación de rutas — verifique su accesibilidad directamente (haga ping o revise la ruta estática específica), no comprobando qué ruta prefiere actualmente la tabla.
SÍNTOMAUn paquete que claramente debería activar la regla más específica — por ejemplo, la que coincide con una dirección de origen concreta — en cambio es redirigido por la regla más amplia basada en la aplicación, o viceversa.
CAUSAUna política de tráfico evalúa sus pares clasificador-comportamiento en orden de precedencia — el número de precedencia más bajo primero — y se detiene en la primera coincidencia, igual que una ACL se detiene en su primera regla coincidente. Si la regla más general tiene un número de precedencia más bajo que la más específica, la regla general gana incluso cuando ambas podrían coincidir.
SOLUCIÓNDé a la coincidencia más específica el número de precedencia más bajo, exactamente como en la configuración de trabajo — la coincidencia por dirección de origen está en la precedencia 5, antes de la coincidencia por aplicación en la precedencia 10.
SÍNTOMAEl tráfico que claramente coincide con la ACL usada en un clasificador aun así no se redirige.
CAUSALa política está vinculada con una dirección — entrante en una interfaz específica. Solo evalúa el tráfico cuando llega por esa interfaz exacta en esa dirección; el tráfico que se origina en otro lugar del router, o que llega por una interfaz distinta, nunca pasa por esa política en absoluto.
SOLUCIÓNConfirme por qué interfaz física entra realmente el tráfico en cuestión, y asegúrese de que esa es la interfaz — y dirección — a la que se aplica traffic-policy, no cualquier interfaz de la ruta.
SÍNTOMAAlguien intenta dirigir el tráfico de una fuente específica hacia un next hop específico editando una route-policy aplicada a un protocolo de enrutamiento, y no hace nada para ese tráfico.
CAUSARoute-policy da forma a qué rutas existen y sus atributos en el plano de control — no tiene concepto de «los paquetes de esta fuente específica», solo de rutas y sus atributos tal como los intercambian los protocolos. Dirigir el tráfico de una fuente hacia un next hop específico, sin importar la mejor ruta normal del destino, es una decisión del plano de datos, por paquete — para eso está PBR.
SOLUCIÓNUse PBR cuando el factor decisivo sea algo sobre el propio paquete (origen, protocolo, puerto); use route-policy cuando el factor decisivo sea algo sobre la ruta (qué protocolo la aprendió, sus atributos, si debería redistribuirse).
Esta nota se basa en dos configuraciones concretas: PBR a nivel de interfaz que coincide por dirección de origen y por puerto de destino HTTP con dos destinos de redirección independientes, y una redirección PBR a escala de red superpuesta a una red enrutada por OSPF. No cubre PBR basado en longitud de paquete o marcado DSCP/precedencia, el reparto de carga del tráfico entre más de un next hop de redirección, ni la aplicación del enrutamiento basado en políticas en sentido saliente en lugar de entrante. Tampoco cubre route-policy en profundidad — route-policy da forma a rutas, no a paquetes, y merece su propio tratamiento; lo que hay aquí es solo la distinción necesaria para elegir la herramienta correcta.
Extraídas de los mismos casos de configuración en los que se basa esta nota.
No — solo se antepone para el tráfico coincidente. Todo lo que un clasificador de tráfico no hace coincidir explícitamente sigue recayendo en la tabla de enrutamiento normal, exactamente como si PBR no estuviera configurado en absoluto.
Sí — cualquier cosa que una ACL (o un clasificador de tráfico más complejo) pueda expresar es válida: origen, destino, protocolo, rangos de puertos, y más. Los dos ejemplos aquí — dirección de origen y puerto de destino HTTP — son simplemente los que ilustra la configuración de trabajo subyacente.
Route-policy actúa sobre las rutas mismas — filtrando o etiquetando lo que un protocolo de enrutamiento aprende o anuncia. PBR actúa sobre paquetes que ya llegaron — redirigiéndolos a un next hop específico según un clasificador de tráfico, sin cambiar ninguna ruta ni atributo de ruta. Vea la comparación en la sección de configuración anterior para la distinción completa.
Está relacionado pero es distinto. Eso suele construirse con rutas estáticas de preferencia igual o desigual (para reparto de carga o primario/respaldo) en lugar de una redirección de política de tráfico — vea nuestra nota de configuración de conmutación por error en doble WAN y reparto de carga para ese diseño específico.
Sí — redirect ip-nexthop igual necesita que esa dirección de next hop sea realmente alcanzable; PBR decide que un paquete coincidente va allí, pero no fabrica accesibilidad. Como muestra la trampa 2 anterior, esa ruta no necesita ser la ruta preferida propia de la tabla de enrutamiento para el prefijo, solo necesita existir.
La palabra clave de configuración admite ambas direcciones, pero el sentido entrante en la interfaz por donde el tráfico realmente se origina desde la fuente que está haciendo coincidir es, con diferencia, la ubicación más común y predecible — captura el tráfico en el punto más temprano, antes de que cualquier otra decisión de reenvío tenga oportunidad de aplicarse.
Cuéntenos qué tráfico — por origen, aplicación o enlace — necesita ir adónde, y le ayudaremos a escribir correctamente el clasificador y el orden de precedencia.