Configuring two T1 lines in cisco 2600 (Total 4 Mbps) from two diffferent providers

There are QoS techniques such as MLPPP that can bundle multiple physical links into one logical link, but only when connected to the same provider. Load balancing is not an option either for the same reason. What you can do is Multihomed Load Sharing to the different providers by using route maps. The first route map will permit public IP addresses up 128.0.0.0 on the first serial interface. The second route map will permit public IP addresses above 128.0.0.0 on the second serial interface. Below is a example of what a Multihomed Load Sharing configuration with two T-1s (1.5Mbps) should look like.

Good Luck

interface Serial 0/0 Description T1 TO PROVIDER-1 ip address 11.11.11.11 255.255.255.252 no ip route-cache

interface Serial 0/1 Description T1 TO PROVIDER-2 ip address 22.22.22.22 255.255.255.252 no ip route-cache

router bgp 300 neighbor 11.11.11.10 remote-as 111 neighbor 11.11.11.10 route-map PROVIDER-1 in neighbor 22.22.22.21 remote-as 222 neighbor 22.22.22.21 route-map PROVIDER-2 in auto-summary

route-map PROVIDER-1 permit 10 match ip address 1 set weight 100

route-map PROVIDER-1 permit 20 match ip address 2

route-map PROVIDER-2 permit 10 match ip address 1

route-map PROVIDER-2 permit 20 match ip address 2 set weight 100

access-list 1 permit 0.0.0.0 127.255.255.255 access-list 2 deny 0.0.0.0 127.255.255.255 access-list 2 permit any

Ahh but wont the other ISP have to talk BGP to his router?

Cheers

Matt

The usual way to do this if you don't have you own IP address allocation is to use policy based routing to route certain traffic out of one port or other, and other traffic out of the other port.

You then NAT on the external interfaces.

Since the traffic is NATted differently for each port, the return traffic gets correctly routed.

Clearly this "statically configured" load balancing is unlikely to produce optimal load balancing however it may be what you want.

The following will allow you to achieve resilience with PBR.

Just add NAT stir and bake for 40 mins.

Just be prepared for egg on your face and have your resume ready...

PBR Support for Multiple Tracking Options appears to only be supported in Enterprise feature sets. So first you will need to upgrade your router (at considerable cost, last time I checked, but that depends upon the platform and assumes your platform is hefty enough to support it. Flash and/or RAM upgrades may also be required).

Once you upgrade it, you will discover using NAT with PBR requires use of policy based NAT, which also works, but uncovers a nasty side effect of Cisco's policy based NAT implementation. Policy based NAT is only used to determine a NAT if there is no NAT for that flow already in the NAT connection table. Once a NAT entry is in the table, it will always be used regardless of the actual path taken by the packet. A connection stays in the table until either it times out or an interface defining its address fails.

Way cool and groovy combination of features, except it doesn't work because of the details of how the individual features are implemented. On the other hand, if you can set it up so that the router doing the policy based routing does not need to NAT on both outside links, then you truly are way cool and groovy.

Been there, done that, been burnt... fortunately the cooking was done in the lab before committing to production, so the damage was minimal. But a classic example of "In theory, there is no difference between theory and practice. In practice, there is."

Good luck and have fun!