Information Technology Reference
In-Depth Information
scenario. If the ISP manually controls the traffic policy, this increases the support burden
and the amount of configuration on the edge routers, increasing the likelihood of configu-
ration errors.
A customer that is multihomed to multiple ISPs might want to use one of the ISPs for transit
and the other just to reach locations local to that ISP. This can be complicated to configure
on a per-customer basis. It is much easier to predefine communities for common customer
policy requests that allow the customer to change its policy at any time without any manual
intervention by the ISP.
The next two sections provide examples of how an ISP can define a policy to let customers
dynamically influence traffic patterns upstream. This is accomplished through local
preference manipulation in the upstream provider's network and by controlling aspects of
the upstream provider's prefix advertisement.
Local Preference Manipulation
The customer can be given the ability to manipulate inbound policy through defining
communities that change the local preference for received prefixes. This allows the
customer that is multihomed to the same ISP to change its inbound routing policy without
manual intervention from the ISP. Table 9-2 shows the community scheme.
Table 9-2
Flexible Upstream Local Preference Communities
Local Preference
BGP Policy Community
80
<ISP ASN>:80
90
<ISP ASN>:90
100 (default)
<ISP ASN>:100
110
<ISP ASN>:110
120
<ISP ASN>:120
The customer can use the communities listed in Table 9-2 to change the local preference of
its routing information in the ISP network. The ISP configuration to implement flexible
local preference is an extension of the inbound customer-facing route maps. The new route
maps are shown in Example 9-6.
Flexible Local Preference Route Map Configuration
Example 9-6
route-map cust_inbound permit 10
match community 10
set community 100:3000 additive
set local-preference 80
