I configured PBR at C4507R-E. When user goes to internet, it match with access-list 181, and traffic should be go to "set ip next hop". But traffic doesn't go to set ip next hop, it send to default route. I configured access-list, route map and apply route map at intervace vlan. From show route-map, I can see that policy routing matches the packets.
Please see attached for show int vlan, sh access-list, sh route-map route-map configuration and debug ip packet 181.
I am not getting why u mention the line 10 deny ip any 10.0.0.0 0.0.0.255.
And you have set your next hop to the same range.
If i am not wrong this ACL is blocking the packet before reaching to the Next hop..
Kindly let me know if i m wrong..
It's used for deny network 10.0.0.x/24. My next hop address is 10.137.221.1 (network 10.137.221.0/24).
From sh access-lists, it doesn't show that line "10 deny ip any 10.0.0.0 0.0.0.255" match with any packet
Your debug does not show any packets being sent from a 10.137.221.x client to the internet (as far as i can see) so it's not possible to say whether it is working or not.
Also you have the next-hop in your PBR reachable back out of the same interface that the PBR is applied to. This is unusual but should work anyway, at least it does on a router with 12.4.
Quickest test is to do a traceroute from a 10.137.221.x client to an internet address and see what the next-hop is from the 4500. Have you done this ? If not could you and see what it says.
Here is the traceroute result:
C:\Documents and Settings\9368>tracert 184.108.40.206
Tracing route to 220.127.116.11 over a maximum of 30 hops
1 38 ms 19 ms 24 ms 10.137.221.9
2 35 ms 22 ms 30 ms 18.104.22.168
3 * * * Request timed out.
4 * * * Request timed out.
C:\Documents and Settings\9368>
22.214.171.124 is default route for 10.137.221.9. Packet goes to default route, should be goes to ip next hop (10.137.221.1).
You can't use Deny statements in PBR. Either it policy routes or it doesn't.
Matches the ACL or doesn't
Just to clarify, you can indeed use deny statements in PBR and in fact that is exactly what you need to do in the above situation. Because the internet can be any address you need to exclude the IP addresses you don't want to PBR ie. the other internal networks. So the above acl has all the denies first, which means don't PBR and then the permit ip any any at the end for the internet traffic.
If you only used permit ip any any that would also PBR internal networks which the OP doesn't want by the looks of it.
Well, there doesn't seem to be any issue with your config.
Is 10.137.221.1 up and reachable from the 4500 ?
Couple of things -
1) can you do a debug as before when you try the traceroute
2) if possible could you simply replace acl 181 with
access-list 101 permit ip any any
and then see if all traffic is being policy routed to 10.137.221. I appreciate this may not be possible.
Nothing else springs to mind unless -
1) it is a bug in the IOS
2) it is because you are sending it back out the same interface. I know this works fine on 12.4 but maybe not on a catalyst switch although i think that unlikely.
Yes, 10.137.221.1 up and reachable from the 4500.
For debug results, I will send it later.
My IOS version is (cat4500e-ENTSERVICESK9-M), Version 12.2(40)SG, RELEASE SOFTWARE (fc2).
"it is because you are sending it back out the same interface."
Please see my topology (attached)
1) For debug result ( debug ip packet 181 - result of traceroute ACL 181) please see attached
2. "access-list 101 permit ip any any" brought some congestion on the core. So I didn't captured.
How about topology, is possible PBR configured with that topology?