am currently experiencing and issue with a route map.

i believe the route-map to be configured correctly but the route map does not appear to be matching the acl

GigabitEthernet0/0 is up, line protocol is up

  Internet address is 172.20.38.254/16

interface GigabitEthernet0/0

ip address 172.20.38.254 255.255.0.0

ip route-cache flow

ip policy route-map EXC-DAG

route-map assigned to interface

show ip int gi0/0

Policy routing is enabled, using route map EXC-DAG

route-map EXC-DAG, permit, sequence 20

  Match clauses:

    ip address (access-lists): 150

  Set clauses:

    ip next-hop 172.20.57.234

  Policy routing matches: 0 packets, 0 bytes

Policy routing is enabled, using route map EXC-DAG

access-list 150 permit ip 192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255

show access-list 150

10 permit ip 192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255 log (3 matches)

show route-map

route-map EXC-DAG, permit, sequence 20

  Match clauses:

    ip address (access-lists): 150

  Set clauses:

    ip next-hop 172.20.57.234

  Policy routing matches: 0 packets, 0 bytes <<<<

i dont think i am missing anything from the configuration

any ideas?

thanks in adviance.

Hello,

You can policy route via the data plane ( that is traffic traversing your router) or Control plane( traffic originating from the router) by specifying acls, protocol types and port numbers

For Data plane PBR you specify the policy on the interface from where the traffic is travesing from -

int xx

ip policy route-map TST

For Control plane you specify the policy globally on the router the traffic originates from -

conf t

ip local policy route-map TST

In your policy you are using acl 150 to specify traffic originating from  interface gig0/0 between

192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255 to be routed out of the next hop interface of

172.20.57.234 -

Is this what you want to happen?

Also you have no resiliency set in place, so if the next hop  interface is unreachable your present policy will still try to forward  traffic based on the match statements and start arping for the next hop  address.

apply set ip next-hp verify-availability into  the policy so in this way the router will do a cdp lookup for the  next-hop address before policy routing and if not found will instead  route normal.

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

Can you disable CEF and check

.

Also in the ACL you have use log keyword can you remove that and check.

show access-list 150

10 permit ip 192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255 log

Do not use the "log" key word on ACLs when using PBR.  Here is a note from Cisco.

"The log keyword should not be used with this command in policy-based routing (PBR) because logging is not supported at the interrupt level for ACLs."

I believe that there is a simple logic problem here that is causing PBR to not work as desired.

First notice the subnet configured on the interface where PBR is configured

interface GigabitEthernet0/0

ip address 172.20.38.254 255.255.0.0

Then notice the source address specified in the ACL used with PBR

access-list 150 permit ip 192.168.4.0 0.0.0.255 192.168.3.0 0.0.0.255

So my question is whether 192.168.4.0 is really connected through interface Gig0/0? That is the only way that PBR configured like this will work.

HTH

Rick

Hi

And thanks for the speedy responses, your input has been very helpful.

i have since been able to  get it to work this morning.

the device connected on this interface Gi0/0  is a firewall that had a missing routing entry.

added the following static route 192.168.3.0 255.255.255.0   use    172.20.38.254   255.255.255.0 

192.168.3.0     172.20.38.254   255.255.255.0   UG

route-map EXC-DAG, permit, sequence 20

  Match clauses:

    ip address (access-lists): 150

  Set clauses:

    ip next-hop 172.20.57.234

  Policy routing matches: 3075964 packets, 555386572 bytes

Thanks to you all for you imput, Apprecitated.

Paul,

cant seem to rate your post. shame as it was very informative!

thanks

ray