Multihomed NAT Balancing Problem

[Ellad Yatsko]

Hello!

I've trouble with NAT. CE has two uplinks. Two ISPs, two /30 networks. I'd like to utilize both connections in the following manner:

interface FastEthernet0/0.101
 description UL:pe.m34:gi0/1.1206
 encapsulation dot1Q 101
 ip address 194.87.6.70 255.255.255.252
 ip nat outside
!
interface FastEthernet0/0.102
 description UL:pe.m34:gi0/1.1207
 encapsulation dot1Q 102
 ip address 194.87.6.74 255.255.255.252
 ip nat outside
!
interface FastEthernet0/0.10
 description DL:users
 encapsulation dot1Q 10
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
!
!
ip nat inside source list 101 interface FastEthernet0/0.101 overload
ip nat inside source list 102 interface FastEthernet0/0.102 overload
access-list 101 permit ip 192.168.0.0 0.0.255.255 any
access-list 102 permit ip 192.168.0.0 0.0.255.255 any
!
!
ip route 0.0.0.0 128.0.0.0 194.87.6.69 10 track 1
ip route 128.0.0.0 128.0.0.0 194.87.6.73 10 track 2
ip route 0.0.0.0 128.0.0.0 194.87.6.73 200
ip route 128.0.0.0 128.0.0.0 194.87.6.69 200
!
!
ip sla monitor 1
 type echo protocol ipIcmpEcho 194.87.6.69
 timeout 2000
 threshold 10000
 frequency 2
!
ip sla monitor schedule 1 life forever start-time now
!
track 1 rtr 1
!
!
ip sla monitor 2
 type echo protocol ipIcmpEcho 194.87.6.73
 timeout 2000
 threshold 10000
 frequency 2
!
ip sla monitor schedule 2 life forever start-time now
!
track 2 rtr 2
!

As supposed - "the first half of Internet" - "on the left",   the rest - "on the right". And also there is redundancy - if one of the links goes down its route is automatically moved on the remaining "live" link. Addresses 0...127.x.x.x are routed to exit through Fa0/0.101 and NATted to 194.87.6.70, addresses 128...223.x.x.x are routed to exit through Fa0/0.102 and NATted to 194.87.6.74. Reverse traffis will come in the same interface as the traffic destined TO Internet passed through - because of SrcIP (194.87.6.70, 194.87.6.74) becomes DstIP and packet routed by provider to the corresponging interface (Fa0/0.101,Fa0/0.102).

The problem is: when both links are alive, the SrcIP on the second (Fa0/0.102) is NATted to 194.87.6.70 instead of expected 194.87.6.74.This leads to the following traffic distribution:

- traffic destined to 0.0.0.0/1 goes "in/out" through Fa0/0.101

- traffic destined to 128.0.0.0/1 goes "out" through Fa0/0.102, but returns back through the Fa0/0.101.

As I invesigated, in both cases NAT translates SrcIP according to the first rule, i. e. this one:

ip nat inside source list 101 interface FastEthernet0/0.101 overload

Because conditions are true - SrcIP=192.168.x.x falls under both access-lists 101 and 102. So it picks THE FIRST AVAILABLE RULE for translation.

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

Is there way to make NAT to translate exactly to the address OF OUTGOING interface (no to the addres OF THE RULE)? Can I bind interface to access-list rule, or tracking object to the NAT rule? Another ways?..

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

Kind regards,

Ellad

[Ellad Yatsko]

I forgot to say about platform:

ce.sudo.gaz.m34#sh ver | i image|memory
System image file is "flash:c2600-advipservicesk9-mz.124-25d.bin"
Cisco 2650XM (MPC860P) processor (revision 1.0) with 118784K/12288K bytes of memory.
ce.sudo.gaz.m34#

[Jose Lopez · Accepted solution]

Check that link:

http://docwiki.cisco.com/wiki/NAT_failover_with_DUAL_ISP_on_a_router_Configuration_Example

[Ellad Yatsko]

You're right Jose! Super! It's working! :-) Thanks a lot!

[Deepak Kumar]

Hi, 

Can you check CEF for load balancing algorithm?

Regards,

Deepak Kumar 

[Ellad Yatsko]

You know, I think CEF is not a cause because we have two DIFFERENT routes, not the same ones. So, there is no place for ECMP. The task was to bind NAT Address to Transit Interface.

[rais]

How about:

access-list 101 permit ip 192.168.0.0 0.0.127.255 any
access-list 102 permit ip 192.168.128.0 0.0.127.255 any

HTH. 

[Ellad Yatsko]

No, it is not good idea, they will be NATted to the same IP. Besides, what will be during a link failure? One half of internal user will be left without an access to Internet. Not a good idea.. :-(

[Georg Pauwen · Accepted solution]

Hello,

try route maps as listed below:

ip nat inside source route-map ISP1 interface FastEthernet0/0.101 overload
ip nat inside source route-map ISP2 interface FastEthernet0/0.102 overload
!
route-map ISP1 permit 10
match ip address 1
match interface FastEthernet0/0.101
!
route-map ISP1 permit 20
!
route-map ISP2 permit 10
match ip address 1
match interface FastEthernet0/0.102
!
route-map ISP2 permit 20

[Ellad Yatsko]

Yes! :-) The same as previous, but I'm not sure we need "permit 20"statements.

[Georg Pauwen]

Hello,

the permit 20 statements are needed to allow everything else in case of a failure.

[Georg Pauwen · Accepted solution]

In addition, I would implement the EEM script below to clear the NAT translations for the tracked inside gobal IP addresses in case the tracked objects change state:

event manager applet CLEAR_NAT_ISP_1
event track 1 state down
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation inside 194.87.6.70"

event manager applet CLEAR_NAT_ISP_1
event track 1 state up
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation inside 194.87.6.74"

event manager applet CLEAR_NAT_ISP_2
event track 2 state down
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation inside 194.87.6.74"

event manager applet CLEAR_NAT_ISP_2
event track 2 state up
action 1.0 cli command "enable"
action 2.0 cli command "clear ip nat translation inside 194.87.6.70"

[Ellad Yatsko]

Thanks a lot!