[c-nsp] What is wrong with this config? (nat load sharing)

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Feeny wrote:
|
| I have a customer who has 2 Internet providers.  They wish to do load
| balancing and BGP is not an option for them.  All of their machines are
| on private IP's.  So I came up with a config where I run NAT behind both
| providers, and in theory it should work no problems, but I am seeing
| where it will load half a web site, like amazon, or apple.com, etc.  And
| then just stall.  Its not DNS, because they are using the one provider
| for DNS, who is in turn allowing both NAT ip's to recursive lookup off
| their servers.
|
| A few observances:
|
| 1) with ip route-cache or ip route-cache flow I was seeing the problem
| with sites stalling out.
| 2) with ip cef enabled it actually works, although the traffic pattern
| is a bit wierd.  It goes between high input/low output on Serial0, and
| low input/high output on s1.1, and  then it will flip flop in time.  I
| am going to graph this to make sure its actually got some pattern to it.
|
| What I don't understand:
|
| 1) Why with fast or flow switching, it would not work.  I liked the idea
| of setting up flow switching, so that their is a 0.0.0.0 coin toss done
| for each flow.
|

Since you have equal cost routes, destination prefixes will be alternated
between the two outbounds.  The route-cache is aged out on a periodic basis
which means that a given prefix that was assigned to Serial0 may get aged
out of the cache and the next lookup for that prefix has a good probabality
of having the outbound interface changed to Serial1.1.  Your existing NAT
translations for in-process connections will be invalid and existing TCP
sessions will likely be reset.  For websites, this is generally observed as
page hangs.  I've seen this before when there were multiple outbound paths
that had independent caches or a cache on only one of the outbound paths.

Now, it works for CEF because CEF hashes the source and destination
addresses in every packet to maintain a consistent path.  Here is an
explanation of CEF from Rodney Dunn that was recently posted on this list:

"The goal of CEF was to solve the the cache maintenance issue that existed
with fastswitching and in the process give better load distribution for
routes with equal cost paths. To solve the cache maintenance issue CEF
simply installs a FIB entry for any given route that is in the routing
table and that FIB entry points to a corresponding adjacency entry that
holds the mac header rewrite to forward the packet. If there are equal cost
paths there will be a loadinfo/pathinfo table that holds pointers to the
various paths.  The question is in this scenario how does CEF decide which
path to take?  For *every* packet CEF does a hash of the src/dst ip address
in the packet and the result is one of the paths. Therefore for every
single packet between a given set of src/dst ip addresses those packets
will always take the same path.  To see the result of that hash you can
do: 	sh ip cef exact-route <src> <dst>
Therefore, by default with CEF you never have an out of order packet
problem because all packets for a given src/dst ip address pair follow the
same path. You don't have a cache maintenance problem because the FIB is
directly programmed from the routing table and you don't age out entries."

Look in the archives for the complete discussion of switching paths and
load sharing or contact me privately and I'll forward his post to you.

| The config is below.  If anyone has any suggestions, please let me know,
| as I am interested in making the sharing as ideal as it can be.  Turning
| off route-caching entirely is not an option however :)
|
|
| interface FastEthernet0
|  ip address 192.168.1.1 255.255.255.0
|  ip nat inside
|  speed auto
| !
| interface Serial0
|  description ShreveNet T1
|  ip address 207.254.221.150 255.255.255.252
|  ip nat outside
| !
| interface Serial1
|  no ip address
|  encapsulation frame-relay IETF
|  frame-relay lmi-type ansi
| !
| interface Serial1.1 point-to-point
|  description ITCDeltaComm
|  ip address 10.20.18.166 255.255.255.252
|  ip nat outside
|  frame-relay interface-dlci 100
| !
| ip nat pool deltacom 66.0.102.177 66.0.102.177 netmask 255.255.255.248
| ip nat inside source route-map ToDeltacom pool deltacom overload
| ip nat inside source route-map ToShreveNet interface Serial0 overload
| ip classless
| ip route 0.0.0.0 0.0.0.0 Serial0
| ip route 0.0.0.0 0.0.0.0 Serial1.1
| ip route 207.254.192.0 255.255.224.0 Serial0
| !


Pointing to interfaces is generally discouraged since it causes the router
to want to ARP.  You should point at next hop IP addresses.


| access-list 1 deny   192.168.1.2
| access-list 1 permit 192.168.1.0 0.0.0.255
| access-list 2 deny   192.168.1.2
| access-list 2 permit 192.168.1.0 0.0.0.255
| !
| route-map ToDeltacom permit 10
|  match ip address 1
|  match interface Serial1.1
| !
| route-map ToShreveNet permit 10
|  match ip address 2
|  match interface Serial0
| !
|
|
| Brian Feeny
|
| ---------------------------------------------
| Brian Feeny, CCIE #8036, CISSP
| Network Engineer
| ShreveNet Inc.
|
|
| ------------------------------------------------------------------------
|
| _______________________________________________
| cisco-nsp mailing list  cisco-nsp at puck.nether.net
| https://puck.nether.net/mailman/listinfo/cisco-nsp
| archive at http://puck.nether.net/pipermail/cisco-nsp/


- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (MingW32)

iD8DBQFBUL9zE1XcgMgrtyYRAmRDAKDmAHdpEQkECMyW7bTNZRPSfGCTMACgti52
9hSyK/vlseG0ZcECXwp4d1Y=
=WI4A
-----END PGP SIGNATURE-----