Default, Primary, and Backup Plus Partial Routing

This is the same scenario as the default, primary, and backup case except that the customer can accept partial routing from the provider. Figure 6-10 illustrates this environment. This approach gives the customer better flexibility in choosing its exit point because more routing information is provided. As previously, both inbound and outbound traffic patterns are discussed.

Figure 6-10  Multihoming/single provider scenario with partial routing.

---

Troubleshooting:  
Ch. 11, pp. 376-382. Default, Primary, and Backup Plus Partial Routing

---

Customer's Outbound Traffic

Consider a situation in which customer 1 is connected to the provider via two separate routers. The customer has the option of deciding which path to take for each of the partial routes it accepts from the provider. This is usually done by setting different local preference for different routes coming into the customer's AS. Local preference can be set on an AS_path or prefix basis or both. If set based on an AS_path, then the local preference will apply to all prefixes contained in a particular AS. In case routing decisions need to be made on a prefix basis, the local preference can be set based on each prefix. In figure 6-10, based on the physical location of certain ASs or prefixes, the customer can choose to forward traffic to customer 2 and customer 3 (C2 and C3) on the SF link and to C4 and C5 on the NY link. The customer can achieve this by doing the following:

•  For routes being learned on the NY link, assign a local preference of 300 for the C4 and C5 routes. Give all other routes a preference of 250 (this would include C2 and C3).

•  For routes being learned on the SF link, assign a local preference of 300 for the C2 and C3 routes. Give all other routes a preference of 200 (this would include C4 and C5).

When presented with multiple routes for the same destination (via external and internal BGP), the customer will prefer the C4 and C5 routes via the NY link (300 > 200). In the same manner, the customer will prefer the C2 and C3 routes via the SF link (300 > 250). For customers other than C2, C3, C4, and C5, the NY link will be preferred (250 > 200).

For all other Internet routes not known to customer 1, default will be taken in the primary backup manner. The 0/0 default route could be dynamically learned from the provider from both ends, or could be statically configured to point to one of the provider's networks (as discussed in the "Setting Default Routes" section of this chapter). Local preference could be used to prefer one default over the other. Based on the way the local preference routes for the C2, C3, C4, and C5 customers were set, all other routes including the 0/0 will be preferred via the NY link (250 > 200).

A totally different approach that doesn't require as much configuration on the customer's side is for the provider to send its metrics toward the customer. This option was discussed in the MED section of Chapter 5. If metrics coming from the provider are representative of how close or how far networks are from the entrance points to the customer networks, then the customer will be able to load balance its outbound traffic accordingly. Traffic toward C4 and C5 will go out on the NY link, and traffic toward C2 and C3 will go out on the SF link. Other traffic will flow depending on what metrics are associated with the routes learned on each link. Although this method requires less configuration, it is also less deterministic on the customer's side because its traffic trajectory is totally dependent on the provider's setup. A combination of both approaches discussed might give the best behavior.

Customer's Inbound Traffic

The customer can influence inbound traffic by advertising different metrics on different links. Some providers encourage their customers to send their internal IGP metrics as BGP metrics (also discussed in Chapter 5). This way, the provider will deliver traffic to the customer via the link closer to the destination. In the example illustrated in figure 6-10, the customer has decided to manually set the metrics to force the following behavior:

•  For routes being sent on the NY link, send the Z and W prefixes with a MED of 200. Give all other prefixes a metric of 250. (This includes X and Y.)

•  For routes being sent on the SF link, send the X and Y prefixes with an MED of 200. Give all other prefixes a metric of 300. (This includes Z and W.)

When presented with multiple routes for the same destinations, the provider will access the Z and W prefixes over the NY link (200 < 300). In the same manner, the provider will access the X and Y prefixes over the SF link (200 < 250). For all prefixes other than X, Y, W, and Z, the provider will choose the NY link (250 < 300).

Default, Primary and Backup, Full and Partial Routing

For customers multihomed to a single provider, the customer can either get full routes on all its connections to the provider, or the customer can have a combination of full routes on one link and no routes (default) or partial routes on the other links. The same techniques discussed in the preceding sections would apply here: local preference is used to control the customer's outbound traffic, and the metric is used to control the inbound traffic. Also, if internal metrics are exchanged between customer and provider, a certain level of load balancing can be achieved.

---

Note:  
Careful! When dealing with outbound traffic, manipulating exit points for specific routes is dangerous. Routing loops can occur if outbound traffic following an IGP default toward the customer's BGP router gets directed toward another router following default to the BGP router. This situation might seem confusing now, but will become more clear in the next chapter.

---