Policy Based Routing advice

Hey all. I'm trying to setup a routing policy on a cat4503-E with Sup6-E and
for some reason I can't see it taking effect. I'm definitely sourcing
packets from 172.25.0.0/16 (the test machine had 172.25.24.25 address). For
some reason the packets still go out towards the default gateway instead of
what's specified in the route-map. The switch is running
cat4500e-ENTSERVICESK9-M), Version 12.2(52)SG, RELEASE SOFTWARE (fc1)
According to stats on the ACL and the route-map it's just not being hit for
some reason. Applying the ACL directly to the interface (as an access-group)
shows that the ACL is correct and I see hits, however, via the route map
it's not being hit. I don't know what those "2 matches" are, but there
definitely should be a lot more than 2. And in addition, I see the packets
arriving on the firewall that is the "default gateway".

Does anyone have any tips on why this might now work?

ip access-list standard acl_Students
  permit 172.25.0.0 0.0.255.255

route-map Students-Route-Map permit 10
match ip address acl_Students
set ip next-hop 192.168.168.22

interface GigabitEthernet2/6
no switchport
ip address 192.168.250.1 255.255.255.252
ip pim dense-mode
ip policy route-map Students-Route-Map

interface GigabitEthernet2/14
no switchport
ip address 192.168.168.21 255.255.255.252
no ip redirects
no ip mroute-cache
flowcontrol send desired

cat4503#sh access-lists acl_Students
Standard IP access list acl_Students
    10 permit 172.25.0.0, wildcard bits 0.0.255.255 (2 matches)

cat4503#sh route-map
route-map Students-Route-Map, permit, sequence 10
  Match clauses:
    ip address (access-lists): acl_Students
  Set clauses:
    ip next-hop 192.168.168.22
  Policy routing matches: 2 packets, 180 bytes

cat4503#sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Redistributing via eigrp 179
  Advertised by eigrp 179
  Routing Descriptor Blocks:
  * 192.168.168.10
      Route metric is 0, traffic share count is 1

I bit more explanation: 172.25/16 is a hop away and the packets with that
source IP will enter on Gi2/6 and need to exit Gi2/14.
So it goes like that:

172.25/16 is vlan25 on the student router
Gi0/1 has ip address 192.168.250.2 on the student router
default route is towards 192.168.250.1 on the student router

Andrey,

It looks like you're doing everything right here so this might seem
like a dumb question, but how sure are you that it's not working?

In my experience on the 4500, 6500, 3560/3750, those ACL/route-map
counters sometimes don't work because of CEF and friends, and at best
they count number of flows that matched the ACL, if even that. Before
knowing this, once upon a time I was absolutely convinced that my
policy routing wasn't working and it turns out that no, the counters
had fooled me. Perhaps try a SPAN session on g2/14 and see whether or
not the packets you expect are exiting that interface, or watch the
interface counters.

HTH,

Bill

I did try an extended ACL and had the same result.
The way I know that it's not working is that I see these packets arriving on
a wrong interface on the firewall and therefor being dropped.
I actually had to open a CR with Cisco and they verified the config and said
nothing is wrong with it. They are escalating and will hopefully get back to
me about this.

Andrey

Have you tried "set interface" instead of "set ip"?

I dont' think this will work. Here is the formal description of "set
interface" from cisco.com:

This action specifies that the packet is forwarded out of the local
interface. The interface must be a Layer 3 interface (no switchports), and
the destination address in the packet must lie within the IP network
assigned to that interface. If the destination address for the packet does
not lie within that network, the packet is dropped.

Since in my case the packets are destined to random addresses on the webz,
my understanding that this will effectively be a drop statement for them.

But, no, I have not tried it.

A 'debug ip policy' should show if it's hitting or not...

IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB flow policy match

IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, len 100,FIB PR flow accelerated!

IP: s=30.0.0.1 (Ethernet0/0/1), d=40.0.0.7, g=10.0.0.8, len 100, FIB
policy routed

Hmmm... The reason I recommended that is because I think I remember reading somewhere that the "set ip" command does not work on point-to-point interfaces. The outbound interface in your config has a /30 assigned to it so maybe it is seeing it as a p-t-p interface?

Do you have a "less preferred" route via that interface for the destination ip's? If not, I don't think your pbr will work either.