Scenario 5: Customers of Different Providers with a Backup Link

It is not unusual for separate ASs to require Internet interconnection and to have different Internet service providers. Whenever multiple providers are involved and the customers of these providers agree to back up one another, support can get complicated. This section takes the previous discussions one step further and discusses how this backup connectivity is addressed from the provider's point of view.

---

Troubleshooting:  
Ch. 11, pp. 394-399. Customers of Different Providers with a Backup Link

---

In figure 6-20, AS1 is the customer of ISP1, and AS2 is the customer of ISP2. AS1 and AS2 have also entered a bilateral agreement under which the private link between the two ASs will be used as a backup in the event of a failure of either primary Internet link. Normally, an individual AS does not want to be used as transit for another AS. In the case illustrated in figure 6-20, AS1 wants ISP1 to set its routing configuration so that ISP1 reaches AS2 via ISP2. Similarly, AS2 would prefer ISP2 to set its routing configuration so that ISP2 reaches AS1 via ISP1. In this scenario, for the backup link to work, AS1 advertises AS2's networks to ISP1, and AS2 advertises AS1's networks to ISP2.

Figure 6-20  Customers of multiple providers with a backup link.

The discussions about primary and backup are the same as with the scenario discussed in the preceding section, "Scenario 4: Customers of the Same Provider with a Backup Link." The private link can be a pure backup or can be used for interior traffic between customers.

The requirement to have the provider not use one customer to reach the other customer is more complicated. ISP1 will have to set the local preference for AS2 routes coming from ISP2 to be higher than the routes coming from AS1.This would cause ISP2 to be used under normal operational conditions. The same strategy might be deployed for ISP2.

Providers, however, would like to minimize configuration on their end as much as possible. In cases where a provider has multiple customers coming online every day, tracking the local preference for each can be cumbersome. Providers would also like to set their policies based on AS numbers rather than specific networks.

A couple of approaches can be used to implement the required policies. The first approach is the community approach, which requires coordination between providers and their customers. The second approach is the AS_path manipulation approach. AS_path manipulation is easier to implement, but might not be available in all vendor products.

The Community Approach

The use of the community attribute becomes very effective. Providers want to map certain community values to corresponding local preference values. Routing updates coming from customers having a specific community will automatically be given the corresponding local preference.

---

Troubleshooting:  
Ch. 11, pp. 394-399. Customers of Different Providers with a Backup Link

---

To keep this scenario manageable, only routing and policy setting from ISP1's point of view is addressed. An identical discussion would apply to ISP2. Traffic flow for the case figure 6-21 illustrated in can be divided into a minimum of three patterns.

Figure 6-21  See Community approach solution.

---

Note:  
There can be more flow patterns, depending on how many connections a customer has to its provider, but the basic set of three illustrates required considerations.

---

Flow patterns from ISP1's point of view can be summarized as follows:

•  Pattern 1—Routes originated by the customer AS1, or customer local routes.

•  Pattern 2—Routes transiting via AS1. These routes come from AS2 and consist of AS2's routes and all other routes that AS2 is receiving from ISP2. ISP1 uses this information to reach AS2 via AS1 as a backup in the event that AS2's link to ISP2 fails. This pattern is referred to as customer transit routes.

•  Pattern 3—All other routes coming from ISP2, or ISP routes. These can include routes learned from AS2.

Having divided the routes into different categories, ISP1 will assign a community value to each pattern and will dynamically map it to the local preference, as listed in table 6-5.

ISP1 will inform all its customers and connected ISPs that its local preference values are dynamically set according to Table 6-5. Customers can then dynamically influence the ISP's decision by sending the corresponding community values. In the example illustrated in figure 6-21, AS1 will send its local routes with no community and the transit routes with community 400:40. ISP2 will send its routes with community 400:60.

According to the preferences summarized in table 6-5, ISP1 prefers AS1's local routes via its direct link to AS1 (preference 100 is the highest). ISP1 prefers all other routes, including AS2 routes, via ISP2 (preference 60 is higher than 40.)