As discussed in earlier chapters, the community attribute that can be attached to BGP routes is extremely helpful in two ways. First, it can instruct upstream networks to perform certain actions for each announced prefix. The second use is to aid a multihomed customer in selecting the better route to a destination from the two received from both transit ISPs.
The oldest use of the community attribute is to adjust the Local Preference of a route in an ISP network, to avoid having to rely on the “weak” MED metric. This is outlined in RFC 1998, “An Application of the BGP Community Attribute in Multi-home Routing.” This RFC uses an example with the Local Preference values listed in Table 11-1.
Table 11-1. RFC 1998 Local Preference values
Customer backup routes
Other ISP routes
This has the advantage of using 100 (the default Local Preference) for customers, so it’s impossible to make a mistake and give customer routes the wrong Local Preference. Because this example comes from MCI, a tier-1 ISP, there is no difference between transit and peer routes for “other ISP routes,” so to apply this to smaller networks it’s necessary to add a “peer routes” category with a Local Preference of 85. This way, routes from peers are always preferred over those received from transit ISPs, which have a slightly lower Local Preference of 80. Customers can set the Local Preference for their announcement ...