Scenario 3: Multihoming to Different Providers

A customer connected to multiple providers is considered to be multihomed to different providers. Redundancy and geographical restrictions are strong motivations for multihoming. The outbound traffic behavior for each iteration of this scenario will be considered on a case-by-case basis. For all cases, the inbound traffic behavior is the same and is covered at the end of the section.

Default Only, Primary and Backup

In this case, the customer can follow defaults toward the provider. One link will be used as primary, and the second link as backup. Figure 6-14 illustrates a relevant situation.

Figure 6-14  Multihoming to two providers.

A customer can set the default routes to the two providers statically or can dynamically learn 0/0 from both providers. The customer can prefer one default over another by using the "distance" or local preference. One good method of pointing defaults to both providers is to accept the same network from both providers. The customer will configure its 0/0 default based on that network and can manipulate local preference to choose one link over the other. In case one default goes away because of a link failure toward one provider, the other default will take its place. The customer can either negotiate with the providers to send him only the one network entry, or the customer can filter all updates on his end except for the one entry.

In Figure 6-14, the customer is pointing the default toward the prefix 192.213.0.0/16 it is receiving from both providers and setting the local preference on the NY link to be higher (200). The NY link will be the primary link, and the SF link will be the backup.

Default, Primary, and Backup Plus Partial Routing

The addition of partial routing to the environment introduced in the previous discussion changes the traffic behavior. Figure 6-15 illustrates the new situation. The customer can accept partial routing from one or both providers and run default toward both providers with one default preferred over the other.

Figure 6-15  Multimihoming to two providers plus partial routing.

By accepting partial routing from the providers, a customer does not need to see all Internet routes and can still make a best route decision when routing toward its direct providers. (For some major providers, partial routes could represent a substantial number of routes.) In the case illustrated in figure 6-15, BGP will make the right choice, and the customer will choose the provider link closest to the destination network (shorter AS_path). For other Internet routes, the basic principal of primary and backup can be used. The customer can point to a specific network to be the default, accept that network from both providers, and use local preference to prefer one link over the other.

Default, Primary and Backup, Full and Partial Routing

In multihoming to different providers, accepting full routes from both or either providers is not really necessary unless the customer plans to be a provider itself and pass along full routes to its customers (act as a transit AS). Figure 6-16 illustrates a relevant environment.

Figure 6-16  Multimihoming to two providers with full and partial routing.

---

Troubleshooting:  
Ch. 11, pp. 387-392. Multihoming to Different Providers

---

The customer can accept full routing from one or both providers depending on how much load balancing he wants to do. In the case of full routing from both (or multiple) providers, the customer can use local preference to decide which networks can be accessed via which provider. Decisions can be made based on AS or prefix information. In some cases, the customer might want to accept full routing from one provider and just do partial/default routing with the other provider. This way, the customer can get the best of both worlds without having to deal with managing full routes from different links. As you will see later, Internet instabilities caused by any provider could cause routers to become very CPU-intensive.

In figure 6-16, the customer is receiving full routes from the NY provider and partial routes from the SF provider. The customer is also pointing a default toward the SF provider. For the SF local and customer routes, the SF link will be used because of the shorter AS_path. For all other routes, the NY link will be used because the SF link is only providing partial routes. In case the SF link goes down, all networks can be reached via NY. In case the NY link goes down, the customer can still reach all Internet routes by following a default toward the SF link.

Customer Inbound Traffic (AS_Path Manipulation)

The inbound traffic is affected by how the customer advertises its networks to the providers. Note that with the multiprovider scenario, sending different metrics from the customer's end will not have any effect. This is because the MED is always terminated at the provider's network and is not carried to the other provider.

To affect the providers' behavior dynamically, the customer can manipulate the AS_path attribute by inserting bogus entries in the AS_path to affect the AS_path length. The providers will receive the same prefix information with different path length and will pick the path with the shortest length. Note that in a multiprovider environment, it is not enough to influence the direct provider only because there is no guarantee that the direct provider will get the traffic itself. Path manipulation will have to influence providers all the way up to the NAP because this is where the balance (as far as path length) will be tipped one way or the other.

Figure 6-17 illustrates how bogus entries in the AS_path affect routing. The customer (AS100) has inserted a bogus entry (100) in its AS_path toward AS300. Providers at the NAP will get the same prefixes with different path length (300 100 100 versus 200 100) and will pick the shorter path via AS200. The bogus entry should be a repeat of the AS that originated the entry (in this case 100).

Figure 6-17  Using bogus AS_path entries to affect routing.