Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Load balancing weirdness using NAT and same-metric route

Hi.

I'm trying to set up a double-WAN load-balancing scenario:

I decided to attempt the "multiple same-metric routes with NAT" approach so I went for the example used in the IOS NAT Load-Balancing for Two ISP Connections Configuration Guide [1].

I decided to use an upside-down Cisco 871-SEC/K9: use Vlan1 and Vlan2 for the routers and Fa4 for the LAN. I am hoping this is not an issue.

There is this weirdness with some connections, particularly FTP. I pinpointed the problem to the following scenario: if I do a couple of pings to 100.1.1.1 using the FastEthernet4 as the source address, this is what I get in the logs:

=== PING 1 ECHO REQUEST ===
*Mar  3 04:38:43.521: IP: tableid=0, s=192.168.60.4 (FastEthernet4), d=100.1.1.1 (Vlan1), routed via RIB
*Mar  3 04:38:43.521: NAT: s=192.168.60.4->10.129.124.2, d=100.1.1.1 [14152]
*Mar  3 04:38:43.521: IP: s=10.129.124.2 (FastEthernet4), d=100.1.1.1 (Vlan1), g=10.129.124.1, len 60, forward
*Mar  3 04:38:43.521:     ICMP type=8, code=0

=== PING 1 ECHO REPLY ===
*Mar  3 04:38:45.589: NAT*: s=100.1.1.1, d=10.129.124.2->192.168.60.4 [19824]
*Mar  3 04:38:45.589: IP: tableid=0, s=100.1.1.1 (Vlan1), d=192.168.60.4 (FastEthernet4), routed via RIB
*Mar  3 04:38:45.589: IP: s=100.1.1.1 (Vlan1), d=192.168.60.4 (FastEthernet4), g=192.168.60.4, len 60, forward
*Mar  3 04:38:45.589:     ICMP type=0, code=0

=== (something else) ===
*Mar  3 04:38:52.353: RT: SET_LAST_RDB for 0.0.0.0/0
  OLD rdb: via 10.129.124.33, Vlan2
  NEW rdb: via 10.129.124.1, Vlan1

=== PING 2 ECHO REQUEST ===
*Mar  3 04:38:52.353: IP: tableid=0, s=192.168.60.4 (FastEthernet4), d=100.1.1.1 (Vlan2), routed via RIB
*Mar  3 04:38:52.353: NAT: s=192.168.60.4->10.129.124.2, d=100.1.1.1 [14159]
*Mar  3 04:38:52.353: IP: s=10.129.124.2 (FastEthernet4), d=100.1.1.1 (Vlan2), g=10.129.124.33, len 60, forward
*Mar  3 04:38:52.353:     ICMP type=8, code=0

=== PING 2 ECHO REPLY ===
*Mar  3 04:38:53.029: NAT*: s=100.1.1.1, d=10.129.124.2->192.168.60.4 [19825]
*Mar  3 04:38:53.029: IP: tableid=0, s=100.1.1.1 (Vlan1), d=192.168.60.4 (FastEthernet4), routed via RIB
*Mar  3 04:38:53.033: IP: s=100.1.1.1 (Vlan1), d=192.168.60.4 (FastEthernet4), g=192.168.60.4, len 60, forward
*Mar  3 04:38:53.033:     ICMP type=0, code=0

In the section "Ping 2 Echo Request" line 2 shows the NAT translating the packet to the address for the first provider but line 3 shows it routing it through the second one.

In this case, the ICMP packet goes through but it is problematic if the ISP restricts the service by source-address (like RPF) or there is some acceleration mechanism inside the provider cloud, other than just plain routing.

What am I missing? Here is the relevant part of the configuration. I deliberately disabled CEF to be able to debug the messages, but I *think* this may be altering the actual router behavior. This router does not have a "debug ip cef packet" command.

no ip cef
!
ip dhcp pool lan-side
   import all
   network 192.168.60.0 255.255.255.0
   default-router 192.168.60.1
   domain-name doublewan.local
   dns-server 8.8.8.8 8.8.4.4
   lease infinite
!
ip domain name doublewan
!
interface FastEthernet0
 !doesn't appear on running-config: vlan 1 is the default access vlan
 !switchport access vlan 1
!         
interface FastEthernet1
 switchport access vlan 2
!
interface FastEthernet2
 shutdown
!
interface FastEthernet3
 shutdown
!
interface FastEthernet4
 ip address 192.168.60.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 no ip route-cache
 duplex auto
 speed auto
!
interface Vlan1
 ip address 10.129.124.2 255.255.255.224
 ip nat outside
 ip virtual-reassembly
 no ip route-cache
!
interface Vlan2
 ip address 10.129.124.35 255.255.255.224
 ip nat outside
 ip virtual-reassembly
 no ip route-cache
!
ip route 0.0.0.0 0.0.0.0 Vlan1 10.129.124.1
ip route 0.0.0.0 0.0.0.0 Vlan2 10.129.124.33
!
!
ip nat inside source route-map nat1 interface Vlan1 overload
ip nat inside source route-map nat2 interface Vlan2 overload
!
ip access-list standard acl4-nexthop-vlan1
 permit 10.129.124.1
ip access-list standard acl4-nexthop-vlan2
 permit 10.129.124.33
!
route-map nat2 permit 10
 match ip address 102
 match ip next-hop acl4-nexthop-vlan2
 match interface Vlan2
!
route-map nat1 permit 10
 match ip address 101
 match ip next-hop acl4-nexthop-vlan1
 match interface Vlan1
!
control-plane
!
!

Of course, there is some configuration pending for redundancy and stuff.

Thanks a lot in advance.

[1] http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/100658-ios-nat-load-balancing-2isp.html

Everyone's tags (1)
1 REPLY

Hello.This might be a bug in

Hello.

This might be a bug in debug command or the IOS (without ip cef) you use; as routing is done before NAT (inside to outside).

To make sure it works fine with ip cef, just enable strict uRPF (or just ACL) on .1 and .33 interfaces and see if you see any packet sent over wrong interface.

PS: please check "sh ip cef 100.1.1.1"; I guess ip cef would tell you "per-destination sharing".

194
Views
0
Helpful
1
Replies
CreatePlease to create content