02-27-2024 10:16 AM
Hello,
I'm having some issues with policy based routing on an ISR-4451, IOS ver. 3.16.06S
Basically, the goal is to redirect internet traffic for a specific set of devices to a different next hop, while leaving internal traffic and all other devices on the subnet alone.
Here's the test config I have for that:
ip access-list extended VLAN12
deny ip 192.168.250.0 0.0.0.255 192.200.0.0 0.0.255.255
deny ip 192.168.250.0 0.0.0.255 192.168.0.0 0.0.255.255
deny ip 192.168.250.0 0.0.0.255 172.16.0.0 0.15.255.255
deny ip 192.168.250.0 0.0.0.255 10.0.0.0 0.255.255.255
permit ip host 192.168.250.12 any
!
route-map TEST permit 10
match ip address VLAN12
set ip next-hop 10.250.0.254
!
interface TenGigabitEthernet2/0/4.12
description Data VLAN 12
encapsulation dot1Q 12
ip address 192.168.250.253 255.255.255.0
ip policy route-map TEST
The problem I'm running into is that traffic for 192.168.250.12 passes just fine, but any other device on the subnet fails to exit the router. The traceroute looks something like this:
Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.250.253
2 * * * Request timed out
I've tried a handful of things with no success:
Unfortunately I just keep getting the same result or blocking the entire subnet from getting out to the next hop.
Anyone have any ideas on where I might be going wrong?
Thanks!
02-27-2024 11:52 AM
We do not have enough information about your environment to be able to understand the issue. Posting the complete config would be a good starting point. Here are a few other things to consider:
- is there a correct/functioning default route for non PBR traffic? The output of show ip route might be helpful.
- is there address translation for non PBR traffic?
- does this router connect directly to outside, or is the next hop some type of security device? And if so are there any policies that impact this traffic?
02-27-2024 11:58 AM - edited 02-27-2024 12:56 PM
Debup ip policy
I think the R can not resolve the next hop because it not direct connection or it limitation of R so you need to specify interface in set commands
But let see debug first
MHM
02-27-2024 12:54 PM - edited 02-27-2024 12:56 PM
Thanks for leading me in the right direction! I shifted focus towards the next hop and it turns out I just had a serious case of tunnel vision.
Both PBR and non-PBR traffic are going out to two different firewalls in this config. As it turns out, the firewall that non-PBR traffic was being directed to did not have a route back to 192.168.250.0/24. Once I added that route it worked as intended.
Since that subnet has only ever been used for testing PBR to a next hop that isn't the gateway of last resort I guess I just never thought to add that.
I appreciate the help with this!
02-27-2024 01:56 PM
You are welcome. Glad that our suggestions were helpful and that you have found the solution to your issue.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide