BGP associates several
different basic attributes with each route prefix. These attributes include
useful pieces of information about the route, where it came from, and how to
reach it. Well-known attributes must be supported by every BGP
implementation. Some well-known attributes are mandatory. All of the
mandatory attributes must be included with every route entry. A BGP
router will generate an error message if it receives a route that is missing one
or more well-known mandatory attributes.
There are also well-known discretionary attributes,
which every BGP router must recognize and support, but they don't have to be
present with every route entry. Whenever a router passes along a route that it
has learned via BGP to another BGP peer, it must include all of the well-known
attributes that came with this route, including any discretionary attributes. Of
course, the router may need to update some of these attributes before passing
them along, to include itself in the path, for example.
BGP routes can also include one or more optional
attributes. These are not necessarily supported by all BGP implementations.
Optional attributes can be either transitive or non-transitive,
which is specified by a special flag in the attribute type field. If a router
receives a route with a transitive optional attribute, it will pass this
information along intact to other BGP routers, even if it doesn't understand the
option. The router will mark the Partial bit in the attribute flags to indicate
that it was unable to handle this attribute, however.
The router will quietly drop any unrecognized non-transitive
optional attributes from the route information without taking any action.
We will now describe several of the most common BGP
attributes.
- ORIGIN
(well-known, mandatory)
This attribute can have one of three different values,
reflecting how the BGP router that was responsible for originating the route
first learned of it. The possible values are:
0 - IGP: The route came from an IGP interior to the originating
AS.
1 - EGP: The route came from an EGP other than BGP.
2 - Incomplete: Any other method.
- AS_PATH
(well-known, mandatory)
The AS_PATH is a list of ASNs, showing the path taken to reach
the destination network. There are actually two types of AS_PATHs. An
AS_SEQUENCE describes the literal path taken to reach the destination, while an
AS_SET is an unordered list of ASNs along the path. Each time a BGP router
passes a route update to an eBGP peer, it updates the AS_PATH variable to
include its own ASN.
- NEXT_HOP
(well-known, mandatory)
This attribute carries the IP address of the first BGP router
along the path to the destination network. When the router installs the route
for the associated prefix in its routing table, it will use this attribute for
the next-hop router. This is where the router will forward its packets for this
destination network.
By default, the NEXT_HOP router will be the router that
announced this route to the AS. For routes learned from an external AS via eBGP,
the NEXT_HOP router will be the first router in the neighboring AS. This
information is passed intact throughout the AS using iBGP, so all routers in the
AS see the same NEXT_HOP router.
- MULTI_EXIT_DISC (optional,
non-transitive)
The Multiple Exit Discriminatory (MED) option is also often
called the BGP Metric. Because this 32-bit value is non-transitive, it is only
propagated to adjacent ASes. Routers can use the MED to help differentiate
between two or more equivalent paths between these ASes.
-
- LOCAL_PREF
(well-known, mandatory)
BGP only distributes Local Preference information with routes
inside of an AS. Routers can use this number to allow the network to favor a
particular exit point to reach a destination network. This information is not
included with eBGP route updates.
- ATOMIC_AGGREGATE (well-known,
discretionary)
When a BGP router aggregates several route prefixes to simplify
the routing tables that it passes to its peers, it usually sets the
ATOMIC_AGGREGATE attribute to indicate that some information has been lost. It
doesn't set this attribute, however, in cases where it uses an AS_SET in its
AS_PATH to show the ASNs of all of the different prefixes being summarized.
- AGGREGATOR
(optional, transitive)
The AGGREGATOR attribute indicates that a router has summarized
a range of prefixes. The router doing the route aggregation can include this
attribute, which will include its own ASN and IP address or router ID.
Both the AGGREGATOR and the ATOMIC_AGGREGATE attributes have
become relatively uncommon since the universal conversion to BGP Version 4.
- COMMUNITY
(optional, transitive)
A COMMUNITY is a logical grouping of networks. This attribute
is defined in RFC 1997, and RFC 1998 describes a useful application of the
concept to ISP networks.
- MP_REACH_NLRI
(optional, non-transitive)
This attribute carries information about reachable
multiprotocol destinations and next-hop routers. Multiprotocol in this context
could refer to any foreign protocol such as IPv6, although it is most commonly
used with IP multicast, MultiProtocol Label
Switching (MPLS) also uses MBGP for per-VPN routing tables.
Carrying foreign routing information this way ensures backward
compatibility. Routers that don't support the extension can easily interoperate
with routers that do.
- MP_UNREACH_NLRI (optional,
non-transitive)
The MP_UNREACH_NLRI attribute is similar to the MP_REACH_NLRI,
except that it carries information about unreachable multiprotocol
destinations.
BGP has several other optional attributes as well, although we
will not discuss them in this book. For more information, we suggest referring
to Internet Routing Architectures (Cisco
Press).
Route Selection
Unlike the various
interior routing protocols that we discussed in the preceding chapters, BGP
doesn't support multipath routing
by default. So, if there are two or more paths to a destination, BGP will go to
great extremes to ensure that only one of them is actually used.
BGP decides which route to use by applying a series of tests in
order. It is important to understand these tests and the order that the router
looks at them, particularly when you are trying to influence which routes are
used. Otherwise you might end up wasting a lot of time trying to adjust your
routing tables using one method, while the router is making the actual decision
at some earlier step, without ever seeing your adjustments.
Note that at each step, there may be several routes to the same
destination prefix that all meet the requirement, or are equal after a
particular test. In that case, BGP will proceed to the next test to attempt to
break the tie.
We should point out that these are the route selection rules on
Cisco routers. Several of these rules are not part of the BGP specification. So,
for non-Cisco equipment, you should consult the vendor's BGP documentation to
see what the differences are.
1.
The first test is whether the next-hop router is
accessible. By default, routers do not update the next-hop attribute when
exchanging routes by iBGP. So it is possible to receive a route whose next-hop
router is actually several hops away, and perhaps unreachable. BGP will not
pass these routes to the main routing table, but it will keep them in its own
route database.
2.
If synchronization is enabled, the router will
ignore any iBGP routes that are not synchronized.
3.
The third test uses the Cisco proprietary weight
parameter, selecting the route with the largest weight. This parameter is not
part of the routing protocol. Adjusting the weight of a particular route on a
router will only affect route selection on this router. It is a purely local
concept. The default weight value is zero, except for locally sourced routes,
which get a default weight of 32,768. The maximum possible weight is 65,535.
4.
If the weights are the same, BGP then selects the
route with the highest Local Preference value from the LOCAL_PREF attribute.
Routers only include this attribute when communicating within an AS (iBGP). For
external routes, the router that receives a particular route via eBGP sets the
Local Preference value. For internal routes, it is set by the router that
introduced the route into BGP. This allows you to force every router in your AS
to preferentially send traffic for a particular destination through a
particular eBGP link.
5.
If two or more routes to the same destination
network are still equal after comparing Local Preference values, the router
moves on to look at the AS_PATH. This is the path vector that gives BGP its
essential character. It is a set of AS numbers that describes the path to the
destination network. BGP routers prefer routes that originate inside their own
ASes. For routes that originate outside of the AS, BGP will prefer the one with
the shortest path (i.e., the one with the fewest ASNs). This is a simple
indication of the most direct path.
6.
BGP then looks at the ORIGIN attribute if the AS
path lengths are the same, and selects IGP routes in preference to EGP, and EGP
in preference to INCOMPLETE routes. An INCOMPLETE route is one that is injected
into BGP via redistribution, so BGP isn't able to vouch for its validity.
7.
The next test looks at the MED, and selects the
route with the lowest value. The MED is used only if both routes are received
from the same AS, or if the command bgp always-compare-med has been
enabled. With this command enabled, BGP will compare MED values even if they
come from different ASes, although to reach this step the AS_PATHs must have
the same length. Note that if you use this command at all, you should use it
throughout the AS or you risk creating routing loops. MED values are only
propagated to adjacent ASes, so routers that are further downstream don't see
them at all.
8.
BGP prefers eBGP to iBGP paths. This helps to
eliminate loops by ensuring that the route selected is the one that leads out
of the AS most directly. Note that the iBGP routes don't include internal
routes that are sourced from within your AS, because they are selected at step
number 5. So this test only looks at routes to external destinations.
9.
The next test compares the IGP costs of the paths
to the next-hop routers, and selects the closest one. This helps to ensure that
faster links and shorter paths are used where possible.
10.Next, BGP will
look at the ages of the routes and use the oldest route to a particular
destination. This is an indication of stability. If two routes are otherwise
equivalent, it is best to use the one that appears to be the most stable.
11.Finally, if
the routes are still equivalent, BGP resorts to the router IDs of the next-hop
routers to break any ties, selecting the next-hop router with the lowest router
ID. Since router IDs are unique, this is guaranteed to eliminate any remaining
duplicate route problems.
Note that there are subtle variations to these rules for
special situations such as AS confederations, and many individual rules can be
disabled if you want the router to skip them.
Cisco has also implemented a BGP multipath option that changes
this route selection process somewhat. If you enable multiple path support, BGP
will still perform the first 7 tests, evaluating everything up to and including
the MED values. But, if two or more routes are still equivalent at this point,
the router will install some or all of them
We would continue to post on BGP for next few days and would try to complete as much topics we can