Policy Based Routing - Not Working

[engineer_msu]

Dear Experts,

I am applying PBR but its not working. I tried a lot and don't find any configuration issue.

Its a simple configuration but still not working.

Please check the below configuration and attached diagram for your reference. Your immediate response is appreciated.

We have two links:

Link	Router IP	ISP IP
ISP-1	87.101.219.114	87.101.219.113
ISP-2	172.31.149.122	172.31.149.121

 Two Sub-Interfaces at LAN

Interface	LAN Subnet	Subnetmask
G0/0	172.27.90.0	255.255.255.0
G0/0.3	172.27.91.0	255.255.255.0

As per BGP policy ISP-1 is the default link. I have applied below PBR configuration so that G0/0.3 users go to ISP-2. But my PBR is not working. I need your help to understand and resolve the issue.

ip access-list extended ITCUsers
 permit ip 172.27.91.0 0.0.0.255 any

route-map ITCUsers permit 10
 match ip address ITCUsers
 set ip default next-hop 87.101.219.113

interface GigabitEthernet0/0.3
 encapsulation dot1Q 3
 ip address 172.27.91.1 255.255.255.0
 ip policy route-map ITCUsers
end

[rakeshvelagala]

Sorry posted on wrong thread

[engineer_msu]

Dears, policy Routing is working when I used Standard Access List / Match the interface in the Route-Map. Now the question is why the Policy Routing is not working with Extended Access-List?

Is there any restriction while using Policy Routing on Sub-interface?

[David Woolfe]

Hi

We may have a similar problem - did you ever get an answer to this?

[Richard Burts]

I believe that the problem in the original poster is in a small detail of how PBR was configured. The original post shows this

set ip default next-hop 87.101.219.113

I believe that it would have worked better if configured in this way

set ip next-hop 87.101.219.113

If David still has a problem with PBR I would encourage him to post his configuration along with a description of the topology and what he wants to accomplish.

HTH

Rick

[David Woolfe]

Thanks Rick

PBR worked ok with a physical LAN interface before changing to dot1q. To be honest I can't be certain if it ever worked with dot1q, it was July last year and I can't remember ever re-testing it again (its at a remote customer site).

It works ok on GNS so I'm wondering if its IOS related (cisco 2811 running c2800nm-entservicesk9-mz.124-24.T3) I'm trying to get hold of a copy of this IOS to lab test.

'engineer_msu' overcame the problem by matching the dot1q interface - I need to use extended ACL as I'm matching specific destination addresses.

My config has 2 WANs, both running BGP, with load-balancing route-maps that monitor a loopback address received from the far end. These set the LP high on WAN1 and low on WAN2 for the loopback, with the reverse for other traffic.

PBR on the LAN looks for a match on the extended ACL and sets the next-hop to the received Loopback address (WAN1), with all other traffic choosing the high LP (WAN2). This whole process allows for eithe WAN link to fail, with all traffic going over the WAN that's up.

I can get round the problem by using tracked IP SLA but I'd rather use the route-map solution.

Config attached.

[David Woolfe]

also, forgot to mention, same process in the opposite direction, matching traffic from the specific address (a server in Birmingham)

[David Woolfe]

The normal routing logic would select WAN2 for the next-hop as it has the higher LP. So PBR forces LP on WAN1 to be higher for the next-hop, only for traffic matching the ACL. The second statement in the route map ensures all other traffic is let through as normal (ie not dropped by the ACL, and with no adjustment to LP so over WAN2). Interesting that PBR doesn't need this!

This does work in practice with the policy map on a physical LAN interface, and probably does on a dot1q interface. I don't have a copy of the particular image we're using, and can't FTP it from the router just yet due to VRFs and pesky firewalls. I'll update this thread for info when I get it and test.

Thanks

David

[Richard Burts]

David

From the standpoint of syntax I see no reason why your PBR would not work. And your explanation of the functionality seems to indicate that the results it would produce should be beneficial. So I would be very interested in hearing results of actually testing it.

Yes the second instance in the route map is an interesting difference in the way that route maps work. If you use a route map for something like setting LP for a BGP prefix then you need an instance in the route map which will set the parameter for selected prefixes and you need a second instance which will allow the other prefixes through with no alternation. But with PBR you only need the single instance which sets the different routing logic. Any packet not selected in the first instance for different routing just gets normal routing and does not need the second instance to achieve it.

HTH

Rick

[David Woolfe]

Thanks Rick

I have the image now, but can't run it on GNS3 :(

So over the next few days I'll club together some routers and set it up, and let you know.

David

[David Woolfe]

Well Richard. After all that, it seems the particular IOS file may have got corrupted. Had a problem after FTP'ing it over and loading onto a test router, it failed verification. Downloaded a different copy and all ok, no problems running the policy map on a dot1q interface.

So have to assume it was that copy of the IOS.

Thanks for checking this over

David 

[Richard Burts]

David

I am glad that you got it worked out and confirm that running the policy map on a dot1q interface does work as expected. Thank you for posting back to the forum to let us know about this.

HTH

Rick

[Richard Burts]

I am not sure where to go with this. Your post says that maybe probably it worked in or until July and that it works in GNS. So I would assume that it would work. But your question sort of implies that maybe it does not work. So what is the real situation?

I have looked at the logic in the partial config that you posted and I do not see any serious issues in the PBR logic. You are applying PBR on the interface where the traffic would seem to arrive, you reference an appropriate access list, and you are doing set ip next-hop recursive. All of which seem to be correct syntax. Without a better understanding of the topology I can not assess whether the PBR really changes how the traffic would be forwarded (where would the recursive lookup for the next hop point and is that different from what the normal routing logic would do?).

I will point out one thing about your config. Your PBR route maps include a second instance like

route-map Load_Balancer permit 20

while the second instance with no match and no set may be needed in functionality like filtering routing updates, it is not needed in PBR. If you remove both of the second instances it will not change the way that PBR works.

HTH

Rick

[engineer_msu]

Dears, I was still not able to use 'Extended Access List' Then I matched the interface as I had to send the traffic coming from this interface to decided ISP

route-map ITCUsers permit 10
 match interface GigabitEthernet0/0.3
 set ip next-hop 87.101.219.113