Although less common today, it use to be quite common for people to want to take two disparate carrier type connections, and make use of them as some sort of “fatpipe” type service. This can be done using CEF and some NAT wizardry. It is preferable to use some other methods, such as OER/PFR if possible, however in some cases you are dealing with certain constraints where “quick and dirty” is what is needed. It’s important to note that the service is not aggregating at the packet level, so you do not get the aggregate amount of bandwidth between the connections available to a single flow. Instead it is balancing the traffic at the flow level, and each flow can use no more bandwidth than it’s single egress connection has available.
This is accomplished primary using CEF, as CEF will do deterministic hashing for its next-hop. Without CEF, you could have bad things happen such as a NAT session could timeout, and a new session created over a different egress link. This would break things like online shopping carts, statefull connections, etc.
Conditional NAT is used on both egress connections. If a connection is lost, CEF will rebalance the hash over the remaining connections.
This only works for balancing outbound traffic. You could try to do some inbound balancing using DNS round robin with the appropriate NAT statements.
In order to manage the device itself remotely (telnet, ssh, etc) you must use local policy routing.
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
enable secret xxxxxxxxxxxxxxxxxxxxx
memory-size iomem 25
no ip domain lookup
ip address 192.168.1.1 255.255.255.0
ip nat inside
ip policy route-map server
1234567891011121314151617 interface Serial0description ISP #1 - ShreveNet T1ip address 184.108.40.206 255.255.255.252ip nat outside!interface Serial1description ISP #2no ip addressencapsulation frame-relay IETFframe-relay lmi-type ansi!interface Serial1.1 point-to-pointdescription ISP #2 - ITCDeltaCommip address 10.20.18.166 255.255.255.252ip nat outsideframe-relay interface-dlci 100!
To remotely reach the router, we must make sure the IP we are managing it on always goes out the interface that it was assigned from (If its an IP from ISP #1 it must take that path, if its an IP from ISP #2 it must take that path. In this example I am managing it using the IP address 220.127.116.11 which is from ISP #1 so I must make sure local policy uses that path.
1 ip local policy route-map local
For ISP #2 we use a pool of one address, for ISP #1 we are doing interface overload
1 ip nat pool deltacom 18.104.22.168 22.214.171.124 netmask 255.255.255.248
If we have a packet trying to exit ISP #1 interface, based on CEF next hop, use an egress IP from ISP #1
If we have a packet trying to exit ISP #2 interface, based on CEF next hop, use an egress IP from ISP #2
12 ip nat inside source route-map ToDeltacom pool deltacom overloadip nat inside source route-map ToShreveNet interface Serial0 overload
192.168.1.2 is our server, it runs a webserver, inbound and only reachable from ISP #1
12 ip nat inside source static tcp 192.168.1.2 80 126.96.36.199 80 extendableip classless
Dual defaults, let CEF build a hash and load share traffic over the two external links
12 ip route 0.0.0.0 0.0.0.0 Serial0ip route 0.0.0.0 0.0.0.0 Serial1.1
Make sure you static route the DNS Servers if you use external DNS from one of your providers, even though 188.8.131.52 may be reachable from any ISP, its only going to allow recursive lookups from IP’s they assigned, which is why we have to make sure we hit that DNS from one of ISP #1’s IP’s. To eliminate this single point of failure, run your own internal DNS with a root cache file
12345 ip route 184.108.40.206 255.255.255.255 Serial0ip route 220.127.116.11 255.255.255.255 Serial0no ip http server!!
In the ACL’s deny the server IP, as it has its own rules (uses ISP #1 always)
1234 access-list 1 deny 192.168.1.2access-list 1 permit 192.168.1.0 0.0.0.255access-list 2 deny 192.168.1.2access-list 2 permit 192.168.1.0 0.0.0.255
Any local management (telnet, etc) use ISP #1, as we are managing from that IP, if ISP #1 goes down we will not be able to reach the router for management, there are ways around this, easiest being try an ISP #2 IP as a second try
1 access-list 103 permit ip any any
server policy route-map, we only have 1 server, this is so inbound connection to the server don’t get screwed up
1 access-list 104 permit ip host 192.168.1.2 any
Route-maps to ensure we use correct interfaces
1234567891011121314151617181920212223 route-map ToDeltacom permit 10match ip address 1match interface Serial1.1!route-map server permit 10match ip address 104set interface Serial0!route-map ToShreveNet permit 10match ip address 2match interface Serial0!route-map local permit 10match ip address 103set interface Serial0!line con 0line aux 0line vty 0 4password xxxxxxxxxlogin!no scheduler allocate
As I said this definitely has its limitations, but is an interesting quick and dirty approach to getting the functionality of using two circuits simultaneously and even allows for a certain amount of resiliency/failover.