El enrutamiento basado en políticas se puede utilizar para cambiar la dirección IP del siguiente salto para el tráfico que coincida con ciertos criterios. Esto puede ser útil para anular su tabla de enrutamiento para ciertos tipos de tráfico. Le mostraré cómo configurar el enrutamiento basado en políticas.
Configuración
Aquí está la topología que usaremos:
Eche un vistazo a la imagen de topología de arriba. OSPF está configurado en todos los routers. Dado que estamos utilizando interfaces Gigabit en todas partes, el tráfico de R1 destinado a 4.4.4.4 normalmente se equilibraría la carga entre R2 y R3. Sin embargo, he cambiado el coste en la interfaz Gigabit Ethernet 0/3 de R1 para que todo el tráfico vaya de R1 > R2 > R4.
Verifiquemos esto:
Encima se puede ver el coste aumentado. Probemos un traceroute rápido desde H1:
Ahora digamos que quiero usar el enlace entre R1 y R3 para llegar a 4.4.4.4. Podría influir en la métrica para OSPF, pero esto se aplica a todo el tráfico. ¿Qué pasa si quiero usar este enlace sólo para cierto tráfico?
Podemos usar el enlace entre R1/R2 para la mayoría de nuestro tráfico y usar el enlace entre R1/R3 sólo para cierto tráfico. Esto puede ser muy útil. Por ejemplo, imagine que el enlace entre R1/R3 es un enlace dedicado que ofrece QoS para el tráfico de VoIP.
Esto es algo que podemos conseguir con PBR (Policy Based Routing) ¡Déjeme mostrarle cómo!
Ahora mismo, todo el tráfico se envía hacia R2:
R1#show ip route | include 4.4.4.4O 4.4.4.4 via 192.168.12.2, 00:16:48, GigabitEthernet0/2
Ahora digamos que queremos que todo el tráfico ICMP de H1 destinado a 4.4.4.4 cruce el enlace entre R1/R3. Así es como se hace:
R1(config)#ip access-list extended ICMP_H1R1(config-ext-nacl)#permit icmp host 192.168.1.100 host 4.4.4.4
Primero, creo una lista de acceso que coincide con mi tráfico. Ahora tenemos que crear un mapa de ruta:
Cuando el tráfico coincide con la lista de acceso, vamos a cambiar el siguiente salto a 192.168.13.3 (R3).
Por último, pero no menos importante, vamos a activarlo:
R1(config)#interface GigabitEthernet 0/1R1(config-if)#ip policy route-map PBR_H1
Veamos si funciona, para verlo en acción voy a habilitar un debug en R1:
R1#debug ip policy Policy routing debugging is on
Ahora enviemos un ping desde H1:
El ping funciona, veamos qué opina R1 de él:
Arriba podéis ver que se ha enrutado la política hacia 192.168.13.3. También podemos verificar esto mirando el mapa de ruta:
Probemos algún tráfico que no coincida con nuestra lista de acceso. Telnet, por ejemplo:
H1#telnet 4.4.4.4Trying 4.4.4.4 ... Open
H1 puede conectarse pero no está enrutado por políticas:
R1#IP: s=192.168.1.100 (GigabitEthernet0/1), d=4.4.4.4, len 40, FIB policy rejected(no match) - normal forwarding
Como puedes ver arriba, este tráfico de telnet se enruta usando la ruta normal.
Hay una cosa más que me gustaría mostrarte. Con el enrutamiento basado en políticas, hay una diferencia entre el tráfico que va a través del router y el tráfico que se origina en el router.
El ejemplo anterior es para el tráfico que pasó por nuestro router. ¿Qué pasa si queremos el tráfico de la ruta de la política que se origina a partir de R1? Tendremos que utilizar otro comando para activarlo. Vamos a crear otro route-map:
El route-map anterior redirigirá todo el tráfico de R1 a 4.4.4.4 hacia R3. Para activar esto, necesitamos usar otro comando:
R1(config)#ip local policy route-map PBR_R1
Esta vez, necesitamos usar el comando ip local policy. Probemos esto:
Genial, nuestro tráfico desde R1 está enrutado por la política.