The customer wants to use one link as the primary traffic conduit and the other as a backup in case the primary link goes down. For outbound traffic, the customer could configure two static default routes with different administrative distances. This would create a primary route and a floating static route to be used as a backup. The default with the lower distance will be the primary.

However, the customer might want to learn the default route, or a few aggregate routes, dynamically from the provider using BGP. In this case, the ISP or the customer could filter the advertisements so that only minimum necessary routes are sent. The Local Preference attribute could then be used to prefer one default route to the other.

Assume that in the example shown in Figure , the default route to New York is preferred over the default to San Francisco. In normal operations, the customer will use the New York link as the primary link and the San Francisco link as a backup.

For outbound traffic, load balancing is not an option. This is because all traffic is sent over the primary path, and the secondary is kept as the backup. The absence of load balancing is offset by the fact that the customer's router requires less memory and processing power.

As for inbound traffic, the customer must carefully control updates to the provider. The customer can advertise its networks to the provider by way of BGP. This way the provider will have two paths to reach destinations within the customer's network. The customer can influence the routing decisions made by ISP by manipulating the metrics advertised to the ISP. The provider will direct its traffic toward the customer based on the metric value. In Figure , the customer is advertising routes with a metric of 50 toward New York and a metric of 100 toward San Francisco. Therefore, traffic toward the customer will take the New York route. Figure shows the commands needed to configure the customer's boundary router.

Notice in this configuration that default routing is handled by two static routes pointing toward the ISP routers. The default route by way of the New York link is set with a lower administrative distance and therefore will be preferred. The SETMETRIC1 and SETMETRIC2 route maps will influence the ISP to send incoming traffic by way of the primary path, New York. Meanwhile, the BLOCK route map prevents any BGP updates from AS 1 from entering AS 3.

What if this customer were multihomed to two different providers? The customer could control inbound traffic the same way, by manipulating advertised metrics using a route map. As for outbound traffic, the customer either can configure static default routes to the two providers or can dynamically learn a default route from both providers. For static default routes, the administrative distance can be used to prefer one default route over the other, while one dynamically learned route can be preferred using the Local Preference attribute.

One good method of pointing defaults to both providers is to accept the same network from both providers and then statically configure a default route towards that network. The customer can manipulate the local preference of this prefix as it is learned from both providers to choose one link over the other. If one default goes away because of a link failure toward one provider, the other default will take its place.

In Figure , the customer is pointing its default routes toward the prefix 192.213.0.0/16, which it is receiving from both providers. The customer's routers apply a route map to incoming updates. The route map sets the Local Preference attribute so that the New York link is preferred. Therefore, the New York link will be the primary link, and the San Francisco link will be the backup.

Lab Activity e-Lab Activity: Configuring BGP with a Multihomed Connection This lab configures only default routes toward the provider and does not want any part of the Internet routing table using BGP.