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 On Thu, Aug 12, 2010 at 11:16, Andrey Khomyakov <khomyakov.and...@gmail.com> wrote: > 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 > > > >> On Thu, Aug 12, 2010 at 11:54 AM, Andrey Khomyakov < >> khomyakov.and...@gmail.com> wrote: >> >>> 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 >>> >>> -- >>> Andrey Khomyakov >>> [khomyakov.and...@gmail.com] >>> >> >> > > > > -- > Andrey Khomyakov > [khomyakov.and...@gmail.com] >