There are three types of redundancy: backbone redundancy, access redundancy, and hardware redundancy.

The first one is easy: Buy T1 ports from two different providers like AT&T and Sprint, and run a configuration protocol and a border gateway protocol that allows the two autonomous systems to communicate with each other and decide logically on which route data is going to be transferred, based on a preconfigured rule set. That creates redundancy should one of those carriers go dark. If AT&T goes down, you have Sprint. Good to go.

The odds of one of those tier-one providers going down are slim to none. Typically where the problem will happen is within the access loop. Alternatively, the hardware may be at fault.

Local loop redundancy then comes into play. The types are a very expensive option of actually building a new network that is not in place for anyone right now from a different local central office into your building. That requires actually installing copper from that central office into your building. It's going to be an expensive one-time payment of $30,000 to $40,000. The only type of business that would do that is a business that is creating a network operations center where they have a lot of telecom facilities coming in. They will build that out and they will have to work with a local exchange carrier that has fiber. They may have to drop fiber from a different central office and build it in. In some cases there are some fiber providers in local areas that might already have fiber in the ground, and they will primarily use that and light it up, and then do smaller runs from the end points of that fiber into the premise and then back into the central office, but that is not going to be cheap either.

So that's local access redundancy. That is typically the hardest portion of redundancy to build and the part that most companies overlook.

Then you have hardware redundancy. If you have two different carriers, two different local access loops, and you are terminating into one Cisco 3700 series box and running VGP4, you have great redundancy, but if that Cisco goes down, you're down also. There are different configurations for creating back-up options with Cisco routers. Cisco has a couple different protocols where you can have dual routers or 3-router setups whereby you run different configurations. Then you have an incremental cost on equipment, but now you are done with your equipment.

There are definitely redundancy options out there. You have to dig deep to find them. Every one of them is going to be on an individual case basis.

Redundancy comes in many shapes and sizes. Redundancy can refer to redundant local loops, redundant customer and access routers, or redundant connectivity providers. Redundancy can also be used to refer to failover solutions that become active when primary hardware fails, as well as solutions that balance traffic over multiple circuits or bond multiple circuits together. To add to the confusion, there are multiple ways to implement each of these solutions! We group such solutions into three major categories: redundancy, balancing, and bonding.

Protocols

Bonding

How It Works

Speeds

Protocols

MLPPP

MLFR

Load Balancing

How It Works

Load Balancing also known as ECMP (Equal Cost Multi Path) or CEF (Cisco Express Forwarding) can be configured per-packet, per-flow, or per-policy. Most users use per flow, which translates to no more than 1.5Mb per session because T1s are logically separated. Not able to make use of the full bandwidth even if not used by any other user. This option requires an IP address for each link. The users experience connection loss if any T1 goes down if redundancy features are not set. Multi carrier options (Not COVAD or other carriers that do not allow public addresses to traverse their network).

Speeds

Protocols

External Border Gateway Protocol

Cisco Express Forwarding

Types

Shadow T-1

The price for a Shadow T1 is roughly 75% of the price for a full T1, so typically a buyer will just bring in a full T1. They bring in two local access loops. One of the loops will connect to a full 1.5 port, and one of the T1s will connect to a 1.5 port that is being billed for the actual throughput and actually measure the packets across the port and bill accordingly. What you will do is configure the hardware in a fail-over type scenario, so it sees the primary T1 as the only route for all the data unless it goes down, in which case it will send traffic over to the T1 that is on a measured billing rate.

Diverse Local Loop

The carrier has the option to terminate a T1 to their backbone but not to the IP port at that location. Let's say it's in New York City. We can bring both of those T1s into New York City. One of the T1s will terminate on the carrier's IP port in New York City, and we can take the other T1 and route it long haul over the carrier's backbone to a different location, say Atlanta, and hop on an IP port in Atlanta. Theoretically if the carrier's backbone then goes down, it is mostly likely just going to be a router error and it will be localized to one area. New York may go down but Atlanta would still be good. They can route that circuit elsewhere.

But if the central office goes down, both of them go down. If the carrier's IP port router, the big Juniper Edge router goes down, then the redundant link would not hit the edge router but instead hit a different piece of gear that is going to allow private LAN access and back-haul to Atlanta, and you would still be operational through that.

There will be an additional charge because now we are back-hauling per mile to the redundant location. When we price that scenario, we offer different termination points. Where would you like to go? New York, New Jersey, Washington DC, Atlanta, Singapore? Obviously Singapore is going to be a little more expensive, but you can create a back-haul scenario. It's not a very popular scenario. I never recommend it. The only time I sell it is when someone asks for it directly.