Conditional NAT

bapatsubodh · ‎04-09-2010

Hi,

Location A (Router A) and Location B (Router B) are connected to each other using GRE tunnel over internet. All the internet destined traffic reaches to Router B from Router A and also the location B local traffic destined for internet. NAT is performed on the Location B firewall.

Due to ISP failure at Router B, GRE tunnel goes down and users from Location A are not able to access internet as there is no NAT or PAT configured on Router A.

Case 1. GRE tunnel is up , then send all internet traffic into the GRE tunnel to Router B. Router B will then decapsulate the packet NATs it and send to internet. This is normal working.

Case 2. ISP at Router B has failed. GRE between Router A and Router B is down.

Check - GRE tunnel - If down - Do the NAT / PAT on router A and send the traffic to internet.

Check - GRE tunnel - Tunnel has been recovered and is up -- STOP NAT / PAT on router A and start sending traffic to GRE tunnel.

Is it possible to do the NAT with help of Track, sla, monitor, route-map or any other logic and then take the corresponding action as that of in Case1 or Case2.

Please share the experience.

Thanks

Subodh

rwagner · ‎04-15-2010

Have you looked at spanning trees?

http://www.cisco.com/en/US/partner/tech/tk389/tk621/technologies_tech_note09186a0080094797.shtml

Spanning trees can make it work so that your routes are re-calculated after a down is detected. Also if you set it up properly then it will return to the origional state after the link comes back up.

visitor68 · ‎04-15-2010

Ryan, what does spanning-tree have to do with what he is trying to achieve? STP is a layer 2 protocol that is used to prevent bridging loops. It is not even remotely related to what he is talking about.

rwagner · ‎04-15-2010

well, spanning trees perform the function of what he was asking for by creating a optimal path and then changing the status of the ports to the other route as "blocking".

So to review the cases I will describe what occurs if they deploy STP that is weighted for Router B.

Case 1: Everything is available

Result 1: GRE Tunnel is up and traffic flows thru Router B as per what is designed as normal.

Case 2: GRE Tunnel goes down.

Result 2: STP recalculates. Places the port for the GRE tunnel in a blocking state and then moves the port for Router A into a forward state. Traffic is now router thru router A.

Case 3: GRE Tunnel comes back up

Result 3: STP recalculates and moves everything to the state existiant in case 1.

From a NAT standpoint you would simply configure NAT to work on both devices. However, ROUTER A will only be used for traffic when ROUTER B is down. I felt that this resolved all conditions presented in the desctiption, but I could see how additional information would make Spanning Trees a poor choice. I do feel that a conditional routing situation will be a better and more easily managed solution that trying to manage traffic routes via a NAT and that is why I made the suggestion.

ohassairi · ‎04-18-2010

i have one config example with the senario:

We have 2 WAN connections to one remote site. Some users connect via connection 1, some others via connection 2. But when one connection comes down all users connect via the other connection automatically

you can modify it according to your settings

hope it helps

!

ip sla monitor 1

type echo protocol ipIcmpEcho 212.0.100.2

ip sla monitor schedule 1 life forever start-time now

ip sla monitor 2

type echo protocol ipIcmpEcho 89.0.100.2

ip sla monitor schedule 2 life forever start-time now

!

track 123 rtr 1 reachability

track 321 rtr 2 reachability

!

interface FastEthernet0/0

ip address 192.168.1.1 255.255.255.0

ip policy route-map mymap1

ip nat inside

!

interface serial0/1

description connection1

ip address 212.0.100.1 255.255.255.252

ip nat outside

!

interface serial 0/2

description connection2

ip address 89.0.100.1 255.255.255.252

ip nat outside

!

access-list 1 permit 192.168.2.0 0.0.0.255

access-list 2 permit 192.168.1.0 0.0.0.255

!

route-map mymap1 permit 10

match ip address 1

set ip next-hop verify-availability 212.0.100.2 10 track 123

set ip next-hop verify-availability 89.0.100.2 20 track 321

!

route-map mymap1 permit 20

match ip address 2

set ip next-hop verify-availability 89.0.100.2 10 track 321

set ip next-hop verify-availability 212.0.100.2 20 track 123

!

access-list 12 permit 192.168.2.0 0.0.0.255

access-list 12 permit 192.168.1.0 0.0.0.255

!

route-map ISP1 permit 10

match ip address 12

match interface serial0/1

!

route-map ISP2 permit 10

match ip address 12

match interface serial0/2

!

Ip nat inside source route-map ISP1

Interface serial0/1 overload

!

Ip nat inside source route-map ISP2

Interface serial0/2 overload