Policy based routing redundant WAN

[rasoftware]

I have a 1801 router with 2 x FE and 1 x ADSL and 1 x SDSL port. I have configured FE0/0 as 172.16.0.0 network and FE0/1 to 10.0.129.0 for LAN PC users. I have two static routes defined 0.0.0.0 out of dialer1 and 2. I have tried to implement Policy Based Routing but it simply doesnt work. Can someone take a look at the config, it look ok and cant see where im going wrong.

[nethelper]

Hello,

what are you trying to accomplish ? Load balancing or source/destination based policy routing, that is, route internal IP addresses with a specific destination out a specified interface ?

Your configuration is missing the access list (40) that is referred to in the route maps, make sure that access list is present.

If you define the access list as:

access-list 40 permit 172.16.0.0

access-list 40 permit 10.0.0.0

with your current router configuration, the router will do outbound, per-destination load-balancing.

If you want to have internal traffic with a specific destination to go out one of the interfaces, you need to specify an extened access list. Let's assume you want traffic from your internal network with a destination address of 192.168.1.0/24 to go out interface Dialer1, the access list needs to look like this:

access-list 101 permit ip 172.16.0.0 0.0.255.255 192.168.1.0 0.0.0.255

access-list 10 permit ip 10.0.0.0 0.0.0.255 192.168.1.0 0.0.0.255

You would then refer to that access list in your route maps.

I hope that clears things up, if not post back.

Nethelper

[rasoftware]

Thanks for the reply.

I want traffic to route from the 10.0.129.0 network firstly via SDSL (dialer1) and if this link fails to route via ADSL (dialer0). I have the static routes but obviously the NAT doesnt work properly. I'm using the PBR to accomplish this but its not working. I think I chopped the access-list 40 out of the posted config, it is there on the router. I did one similar with a FE port and ADSL as fail over and it worked, this however doesnt.

[pkhatri]

Howdy,

You need to use reliable static routing to accomplish what you are after. The use of dialer interfaces does not work with floating static routes because they always remain up.

Here is the set of changes you need to apply to the config you posted (replace with an IP that you can ping through your main link - preferably the ISP side of the WAN link address):

interface FastEthernet0/1

no ip policy route-map nexthop

!

no ip local policy route-map nexthop

!

no ip route 0.0.0.0 0.0.0.0 Dialer1 2

no ip route 0.0.0.0 0.0.0.0 Dialer0 3

!

ip sla monitor 1

type echo protocol ipIcmpEcho

timeout 1000

frequency 3

threshold 2

!

ip sla monitor schedule 1 life forever start-time now

!

track 100 rtr 1 reachability

!

ip route 0.0.0.0 0.0.0.0 Dialer1 track 100

ip route 0.0.0.0 0.0.0.0 Dialer0 254

!

ip local policy route-map LOCAL_POLICY

!

access list 101 permit icmp any host echo

!

route-map LOCAL_POLICY permit 10

match ip address 101

set interface Dialer1

set interface null0

!

With the above config, your primary link will be declared down when you can no longer reach the through it and the backup static default will kick in...

Hope that helps - pls rate the post if it does.

Paresh

[rasoftware]

Thanks very much.

I wonder if that explains when I used PBR with one FE Wan port and 1 Dialer that it worked before. I guess it actual knows the FE primary was down then switched to the dialer asdl as backup. This I gather is not so the case when you have two WAN dialers because they remain "up".

Will this config allow it to switch back to the primary when it comes back up?

[pkhatri · Accepted solution]

I can't really comment on why your previous setup worked (without looking at your configs). The FE wan port would have remained up even if connectivity had been lost further downstream...

This config will correctly switch back to the primary when it comes back up.

Paresh.

[ananddiwakar]

Hie Paresh,

I have jus implemented this solution of reliable static routes which you ahve provided. The things are working pretty fine right now and during the testing, routes were changing as expected.

Have you implemented this solution somewhere and have seen any issues which may arise out of this. I am a bit worried because I have provided this solution for the first time and not sure how this will work under a "full-load test". If you have come across any issues please let me know.

Also, I have not used local policy routes. In the setup there is no routing protocol and I have defined a static route to the network where I am pinging. So the ping packets take only the specified link and are not routed by any other route. Will this cause any issues. Can you provide any valuable feedback on this

Best Regards,

Anand P. Diwakar

[pkhatri]

Hi Anand,

I have not seen any real issues with this. The only thing I advise is to choose the address being pinged carefully. You need to make sure that this address responds to pings consistently or else you will get your link failing needlessly. Also remember that pings are treated as low priority within most networks ....

One other thing is the lcoation of this address - if you are pinging an address at your ISP, you will not find out about failures further downstream (your ISP may have lost connectivity to the Internet) so the deeper into the internet core you ping, the better. This, of course, contradicts my first requirement so you will have to find some trade-off here...

The use of a specific static route for the pinged address is fine and should work okay.

Apart from that, I have not seen any real issues with this setup in production use. It works quite well.

Hope that helps - pls rate the post if it does.

Paresh

[rasoftware]

Thanks very much, this works very well.

Just for interest the config I did before when I had 1 FE0/0 port and 1 ADSL (backup -dialer0) was as follows:

interface FastEthernet0

ip address 195.x.x.x. 255.255.255.252

ip nat outside

interface FastEthernet1

ip address 192.168.151.1 255.255.255.0

ip nat outside

ip policy route-map nexthop

interface dialer0

ip address negotiated

ip nat outside

ip local policy route-map nexthop

ip nat inside source route-map ispA interface Ethernet0 overload

ip nat inside source route-map ispB interface dialer0 overload

access-list 40 remark allow addresses to be NAT'd

access-list 40 permit 192.168.151.0 0.255.255.255

route-map ispA permit 10

match ip address 40

match interface Fastethernet0

route-map ispB permit 10

match ip address 40

match interface dialer0

ip route 0.0.0.0 0.0.0.0 195.x.x.x

ip route dialer0 3

I guess this is possibly because the FE port provided a "reliable" route rather than the "spoofing" dialers do?

[pkhatri]

That really should not have worked unless the way you were testing it was by unplugging the ethernet cable or turning off your modem/NTU ...

Paresh.

[rasoftware]

Yes that how i was testing it! I will change it to the solution you provided.

Once again thanks for your help, it's always appreciated.

[pkhatri]

No probs.. you had me a bit worried there for a while :-)

Paresh

[rasoftware]

Paresh,

I have now implemented this. I seem to have a problem with multihomed NAT. The connection only works when I have 1 NAT entry, add the second can I think it doesnt know which dialer to NAT to from 10.0.129.0 network.

ip nat inside source list 10 interface Dialer0 overload

ip nat inside source list 20 interface Dialer1 overload

!

access-list 10 remark SDM_ACL Category=2

access-list 10 permit 10.0.0.0 0.255.255.255

access-list 20 remark SDM_ACL Category=2

access-list 20 permit 10.0.0.0 0.255.255.255

[pkhatri]

Howdy,

You need to use the route-map form of the ip nat inside command:

ip nat inside source route-map ispA interface dialer1 overload

ip nat inside source route-map ispB interface dialer0 overload

access-list 10 permit 10.0.0.0 0.255.255.255

route-map ispA permit 10

match ip address 10

match interface dialer1

route-map ispB permit 10

match ip address 10

match interface dialer0

Try that out and see how you go.

Paresh