Solved: Policy based Routing. Am I doing it right.

Flyberius · ‎08-22-2012

Last night I had a crack at setting up PBR on my companies Cisco 1811.

Joy, I thought, it's actually working. Alas I was wrong, the addresses were getting translated to our ADSLs external ip address but routed over our EFM.

What I want to acheive is to send all HTTP(s) traffic from our workstations over the ADSL (FastEthernet1) whilst all other traffic and VPN goes out over our Bonded ADSL (FastEthernet0). There is also a minor failover in place for traffic routed to the ADSL in the route-map PBR_VLAN1. The servers are on IPs 200, 202, 204 and 240.

Anyway, I have re-written the configuration and xxx'd and x.a/b/c'd all the IP addresses I want to keep secret. Could one of you kindly cisco guru's make sure that the PBR is correct, and will do what I want it to? I have a very small time-frame to get this correct and I dont want to fudge the bucket so to speak.

Configuration is attached. Thanks in advance.

cadet alain · ‎08-23-2012

Hi,

can you do following when trying to ping from this PC:

-clear access-list counters

-debug ip policy

-conf t

- logging buff 100000

-logging buff debug

-no serv timestamp debug

-do clear log

do your ping and then issue following and post:

do sh log

do sh access-list workstations

Regards.

Alain

Don't forget to rate helpful posts.

View solution in original post

cadet alain · ‎08-22-2012

Hi,

I would change the PBR route-map to set the ip next-hop of f1 and not the interface.

Can you try this and tell us if the PBR is working correctly.

Regards.

Alain

Don't forget to rate helpful posts.

Flyberius · ‎08-22-2012

Thank you Alain,

I will try this later on tonight (I have to wait until the office closes unfortunately).

route-map PBR_VLAN1 permit 10

match ip address workstations

set ip next-hop 80.229.w.y

set ip next-hop recursive 141.0.x.z

Would this still have the effect of routing the workstation traffic to the FE0 interface if FE1 is unavailable? As in my original configuration?

cadet alain · ‎08-22-2012

Hi,

the recursive feature is only when your nex-hop is not on the same subnet.

Now when PBR can't recurse to fe1 it will use the RIB to route the traffic but as you have multipoint interfaces I suggest you use the verify-availabilty feature along with objcet tracking with IP SLA in your set clause.

in this case I would also do a local PBR to force the IP SLA ping test to always use f1 interface as source address.

Regards.

Alain

Don't forget to rate helpful posts.

Flyberius · ‎08-22-2012

Ok, there seems to be a problem.

Whilst it appears that outbound traffic from the workstations is now flowing over the FastEthernet1 interface, if I do a trace to 8.8.8.8 on port 80 from the VLAN1 interface (192.168.2.2) it looks as though it is infact flowing over my FastEthernet0 interface.

Furthermore, if I change my workstations access list to include, permit ICMP host 192.168.2.51 any (my PC), I loose my ability to ping or trace from my PC.

Below are the results of my trace from the device.

---------------------------------------

#trace

Protocol [ip]:

Target IP address: somedomain.com

Source address: 192.168.2.2

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]: 80

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to somedomain.com (188.165.x.x)

1 unknown.griffin.com (141.0.x.g) 4 msec 8 msec 8 msec

2 unknown.griffin.com (141.0.x.i) 4 msec 4 msec 4 msec

3 xe-0-0-0-dot-3014.core01.lon3.as20500.net (109.204.1.40) 4 msec 4 msec 4 msec

4 xe-0-0-1-dot-300.core01.lon5.as20500.net (95.177.0.7) [MPLS: Label 300016 Exp 0] 4 msec 4 msec 4 msec

5 xe-0-0-2-dot-400.core01.lon6.as20500.net (95.177.0.9) [MPLS: Label 300480 Exp 0] 4 msec 4 msec 4 msec

6 xe-0-0-1-dot-100.core01.lon1.as20500.net (95.177.0.2) 4 msec 4 msec 4 msec

7 sw1.tc.lon.ovh.net (195.66.224.220) 4 msec * 4 msec

8 rbx-g2-a9.fr.eu (91.121.128.195) 20 msec 20 msec 24 msec

9 vss-3-6k.fr.eu (213.251.130.77) 20 msec 20 msec *

10 * * *

11 * * *

12

---------------------------------------

Its very strange because if I run a speedtest.net from a PC I get the speeds I would expect from my ADSL line.

If I run it from one of my servers I get the speed I would expect from my EFM/Bonded ADSL line.

But the trace from the Cisco on port 80 is clearly going via the EFM and not the ADSL.

I have uploaded the current running config to this post. I imagine I have probably made an elementary mistake with the routing or the NATing but I can't see it.

cadet alain · ‎08-23-2012

Hi,

when you do the ping from the router then traffic is routed via the RIB and not Policy routed because the PBR you configured is only for traffic forwarde through the router not traffic from the router, in this case you must use local PBR in global config mode: ip local policy route-map command.

Can you show me the modified ACL that denies hosts from pinging or tracerouting( which are both using icmp).

Regards.

Alain

Don't forget to rate helpful posts.

Flyberius · ‎08-23-2012

This is beigining to make some sense. Here is the ACL I using for my PBR route-map.

Extended IP access list workstations

10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

20 deny ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

30 deny ip host 192.168.2.200 any

40 deny ip host 192.168.2.202 any

50 deny ip host 192.168.2.204 any

60 deny ip host 192.168.2.240 any

70 permit tcp 192.168.2.0 0.0.0.255 any eq www

80 permit tcp 192.168.2.0 0.0.0.255 any eq 443

90 deny ip any any

With this configuration it all appeared to be working. To be sure I added the following line to the ACL to run a trace from my PC and I lost all ICMP connectivity from my PC accross the WAN.

Extended IP access list workstations

10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

20 deny ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

30 deny ip host 192.168.2.200 any

40 deny ip host 192.168.2.202 any

50 deny ip host 192.168.2.204 any

60 deny ip host 192.168.2.240 any

65 permit icmp host 192.168.2.51 any <----------------My PC

70 permit tcp 192.168.2.0 0.0.0.255 any eq www

80 permit tcp 192.168.2.0 0.0.0.255 any eq 443

90 deny ip any any

I also tried...

Extended IP access list workstations

10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

20 deny ip 192.168.2.0 0.0.0.255 192.168.3.0 0.0.0.255

30 deny ip host 192.168.2.200 any

40 deny ip host 192.168.2.202 any

50 deny ip host 192.168.2.204 any

60 deny ip host 192.168.2.240 any

65 permit ip host 192.168.2.51 any <----------------My PC

70 permit tcp 192.168.2.0 0.0.0.255 any eq www

80 permit tcp 192.168.2.0 0.0.0.255 any eq 443

90 deny ip any any

I was expecting this to make the PBR on VLAN1 route all my traffic out on FastEthernet1 but instead I lost all connectivity from my PC accross the WAN.

cadet alain · ‎08-23-2012

Hi,

can you do following when trying to ping from this PC:

-clear access-list counters

-debug ip policy

-conf t

- logging buff 100000

-logging buff debug

-no serv timestamp debug

-do clear log

do your ping and then issue following and post:

do sh log

do sh access-list workstations

Regards.

Alain

Don't forget to rate helpful posts.

Flyberius · ‎08-23-2012

I think that it is now working.

I created a "81 permit icmp 192.168.2.0 0.0.0.255 any" and stuck that in the workstation ACL and now my tracerts look good.

I can't thank you enough for your help.

I will mark your post as the correct answer once I have had a day to proove to myself there are no more hiccups.

Once again I am astounded at a stranger's patience and their motivation to help an unqualified nonce like me.

Thankyou, thankyou, thankyou!