> I'm planning on becoming dual homed around the beginning of the year, > with the goals of redundancy, and increased bandwidth. I'd like TLG to > be one ISP, and [other ISP] to be the other. I want to my load to > balance between the two ISPs."Dual home" is vastly more complicated than installing an adequate router and configuration. You absolutely must become familiar with current cloud-level practices and procedures. A lot of the seeming limitations are not technical, but reasonable practice based upon experience.
To start with, address space is not usually portable. Net numbers obtained from an ISP are generally not announcable from another ISP; OTHERnet will not announce TLG-assigned net numbers, nor will we announce theirs. In general, no ISP will anounce an object smaller than /18.
This presents a serious chicken/egg problem to startup ISPs; how do I get redundancy and reliability? How do I get portable addresses?
On the latter, address portability: you need a /18 or larger block assigned from Internic. But you can't get one of those until you have already used a substantial amount of (almost certainly) non-portable space, obtained probably in dribs and drabs from your ISP (ie. TLG).
Address space is assigned by demonstrated previous history -- pingable hosts or netnumbers, not projected by sales, paid for or not. For one or few numbers, you get them from us. We make you demonstrate some sort of reasonable plan for address space usage based upon short term needs. Iff you create an actual history of reasonable address space growth over many months, then you will be allocated larger blocks according to demonstrable need.
We in turn do the same thing; show to our ISPs and neighbors and Internic that we actually use address space, and in a reasonable manner. We are held to the same standard, as is MCI, Sprint etc. We are now large enough that we now get our blocks directly from Internic, but it took over two years of growth.
On top of this, the Internet is growing and things that could be pulled off in a casual manner are now wrapped in procedure, however awkward. The goal is rational and survivable growth in the cloud-level routing tables -- already, the lowest cost router that I know of that can handle "full routes" (30,000+ routes from say MCI and another provider) is a $10,000 Cisco 4000 series with 32MB RAM. Today (October 1995) I can tell you from personal experience that it does not have enough CPU horsepower to survive route-flap storms from the net. 45xx or 47xx series may serve as a delaying tactic.
> In order to increase capacity and improve reliability, I'd like to > obtain a second circuit to one of your other POPs. It's then my > problem to choose which circuit is best for outgoing packets.This isn't the good idea it seems to be -- there's a much simpler solution.
For the reliability issue, you need to ruthlessly consider what it is that fails.
In our experience, it's circuits, circuits, circuits. Nearly all extended outages (> 10 minutes) are caused by leased-line, Frame-Relay, or other circuit failure. Other causes, in informal decreasing order, are human error, power failure, with equipment failure dead last.
Keep in mind that IP is a point-to-point protocol; packets cannot generally have two active, "load balanced", routes. "Load balancing" is always a hack, and done at the hardware (special dual-T1 CSUs), packet (two serials on a Cisco) or route (loopback to loopback BGP route hackery).
The Cisco packet-based solution is by far the best choice, for cost, simplicity, reliability and performance. Two circuits from your site to one of our POPs, and a pair of low cost Cisco 2501's with all four interfaces in the same subnet very nicely provides 3.0MBit service, with fold-back reliability. It requires zero additional complexity above the obvious extra circuit/hardware.
TLG POPs don't go offline in their entirety; even during a particular incident where PG&E scheduled an extended (15 hour) outage for the entire building housing one of our main POPs, only a few Pacific Bell circuits failed, after a few hours, due to insufficient battery capacity in Pacific Bell's central office equipment. Due to our UPSs and our colo's rooftop generators, we were just fine during this outage.
> It gets a little messier if I connect to (BIG-ISP). I don't really see a > way to do it without us being a full AS, and advertising routes.This is the *only* choice for dual-home sites. It is a given, whether one of them is (BIG-ISP) or not. You will have to arrange routing for all of your objects, and get very comfy with the innards of cloud-peer routing, and it is not written down. You will need a router that can hold all the routes you need, manage your address space utilization with SWIP, the route arbiter and other private registries such as the MCI RR where applicable. Most of this is administrative overhead, not technical.
Even with all this, there is no such thing as "load balance", per se. Please consult some of the MCI documentation available on the TLG web server (originally obtained from the MCI FTP server). Even with all the routes two ISPs may give you, there is no guarentee that more or less 50% of the load will go via either ISP. It will go to whichever has the shortest AS path. This FAQ isn't the place to cover this information, and as far as I know none of this is written down in any particular place, and many ISPs will consider this competitive information.
Consider also: when you become your own autonomous system, you automatically are not contained within our ASN, and any peerage agreements we have, that apply to our ASN, will not apply to yours. You will lose all the benefits of our arrangements and agreements with our neighbors. You will then be required to work out your own peerage agreements.