This chapter is from the book
This chapter is from the book
This chapter is from the book
BGP Attributes
BGP attributes are a confusing array of information carried in a BGP update capable of indicating anything from path preference to various additional pieces of information about a route, either within an autonomous system or outside an autonomous system. There are four basic types of attributes:
Well known mandatory attributes; these attributes must be recognized by all BGP speakers, and must be included in all update messages. Almost all of the attributes impacting the path decision process, described in the next section, are well known mandatory attributes.
Well known discretionary attributes; these attributes must be recognized by all BGP speakers, and may be carried in updates, but are not required in every update.
Optional transitive attributes; these attributes may be recognized by some BGP speakers, but not all. They should be preserved and advertised to all peers whether or not they are recognized.
Optional non-transitive attributes; these attributes may be recognized by some BGP speakers, but not all. If an update containing an optional transitive attribute is received, the update should be advertised to peers without the unrecognized attributes.
Figure 1-8 illustrates the way in which attributes are included in a BGP update message.
)
Figure
1-8: Carrying Attributes Within A BGP Update
There are several other attributes not shown in Figure 1-8, but included in BGP, such as Communities and Extended Communities.
Origin Code
The ORIGIN is a well known mandatory attribute that indicates the origin of the prefix, or rather, the way in which the prefix was injected into BGP. There are three origin codes, listed in order or preference:
IGP, meaning the prefix was originated from information learned from an interior gateway protocol
EGP, meaning the prefix originated from the EGP protocol, which BGP replaced
INCOMPLETE, meaning the prefix originated from some unknown source
The following configurations and show command output illustrates two of these origin codes using Cisco IOS Software.
! hostname router-a ! .... ! interface Ethernet1/0 ip address 10.1.12.4 255.255.255.0 ! .... ! interface Serial3/0 ip address 10.0.7.4 255.255.255.0 ! .... ! router bgp 65500 no synchronization bgp log-neighbor-changes network 10.0.10.0 redistribute static metric 10 neighbor 10.0.7.10 remote-as 65501 no auto-summary ! ip classless ip route 10.7.7.0 255.255.255.0 10.1.12.1 ! hostname router-b ! .... ! interface Serial0/0 ip address 10.0.7.10 255.255.255.0 ! .... ! router bgp 65501 no synchronization bgp log-neighbor-changes neighbor 10.0.7.4 remote-as 65500 no auto-summary ! router-b#sho ip bgp BGP table version is 3, local router ID is 10.0.16.10 Status codes: s suppressed, d damped, h history, * valid, > best, i -internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.7.7.0/24 10.0.7.4 10 0 65500 ? *> 10.0.10.0 10.0.7.4 0 0 65500 I
An Origin code of IGP typically suggests that the route was cleanly derived inside the originating AS. An Origin code of EGP suggests that the route was learned via the EGP protocol. Origin codes of Incomplete typically result from aggregation, redistribution, or other indirect ways of installing routes into BGP within the originating AS.
AS Path
The AS_PATH is a well-known mandatory attribute and as described in the section BGP Path Vector Implementation earlier in this chapter, is the list of all autonomous systems the prefixes contained in this update have passed through. The local autonomous system number is added by a BGP speaker when advertising a prefix to an eBGP peer.
Next Hop
The BGP NEXT_HOP is a well-known mandatory attribute. As described in the section Interior and Exterior Peering, earlier in this chapter, the Next Hop attribute is set when a BGP speaker advertises a prefix to a BGP speaker outside its local autonomous system (it may also be set when advertising routes within an AS, this will be discussed in later sections). The Next Hop attribute may also serve as a way to direct traffic to another speaker, rather than the speaker advertising the route itself, as Figure 1-9 illustrates.
)
Figure
1-9: BGP Third Party Next Hop
The following configurations from a router running Cisco IOS Software illustrate Router C using B as the BGP next hop for destinations in AS65500, even though Router C is learning these routes directly from A.
! hostname router-a ! .... ! interface FastEthernet0/1 ip address 10.46.0.10 255.255.255.0 duplex auto speed auto ! .... ! router bgp 65500 no synchronization bgp log-neighbor-changes network 10.46.12.0 neighbor 10.46.0.12 remote-as 65501 neighbor 10.46.0.12 route-map setnexthop out no auto-summary ! .... ! access-list 10 permit 10.46.12.0 ! route-map setnexthop permit 10 match ip address 10 set ip next-hop 10.46.0.11 ! ! hostname router-b ! .... ! interface FastEthernet0/1 ip address 10.46.0.12 255.255.255.0 duplex auto speed auto ! .... ! router bgp 65501 no synchronization bgp log-neighbor-changes neighbor 10.46.0.10 remote-as 65500 no auto-summary ! router-b#show ip bgp BGP table version is 2, local router ID is 208.0.14.12 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.46.12.0 208.0.0.11 0 0 65500
Most BGP implementations deployed today also allow the network administrator to set the BGP next hop when advertising a route between iBGP peers; Figure 1-10, and the following configuration from a router running Cisco IOS Software, illustrates.
)
Figure
1-10: Setting the Next Hop to Self in iBGP
!
hostname router-a
!
....
!
interface Serial3/0
ip address 10.108.7.4 255.255.255.0
!
....
!
router bgp 65500
no synchronization
bgp log-neighbor-changes
network 10.108.12.0 mask 255.255.255.0
neighbor 10.108.7.10 remote-as 65501
no auto-summary
!
!
hostname router-b
!
....
!
interface Serial0/0
ip address 10.108.7.10 255.255.255.0
!
....
!
interface FastEthernet0/1
ip address 10.108.0.10 255.255.255.0
duplex auto
speed auto
!
....
!
router bgp 65501
no synchronization
bgp log-neighbor-changes
neighbor 10.108.0.11 remote-as 65501
neighbor 10.108.0.11 next-hop-self
neighbor 10.108.7.4 remote-as 65500
no auto-summary
!
router-b#show ip bgp
BGP table version is 2, local router ID is 10.108.16.10
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, r RIB-failure
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.108.12.0/24 10.108.7.4 0 0 65500 i
!
hostname router-c
!
....
!
interface FastEthernet0/1
ip address 10.108.0.11 255.255.255.0
duplex auto
speed auto
!
....
!
router bgp 65501
no synchronization
bgp log-neighbor-changes
neighbor 10.108.0.10 remote-as 65501
no auto-summary
!
router-c#show ip bgp
BGP table version is 2, local router ID is 10.108.13.11
Status codes: s suppressed, d damped, h history, * valid, > best,
i - internal, r RIB-failure
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*>i10.108.12.0/24 10.108.0.10 0 100 0 65500 i
The reasoning for why a network administrator would want to do this is discussed in later sections.
Multiple Exit Discriminator (MED)
The MUTLI_EXIT_DISC (MED) is an optional non-transitive attribute that provides a mechanism for the network administrator to convey to adjacent autonomous systems to optimal entry point in the local AS; Figure 1-11 illustrates this concept.
)
Figure
1-11: The Multiple Exit Discriminator
Here, AS 65200 is setting the MED on its T1 exit point to 100, and the MED on its OC3 exit point to 50, with the intended result that the OC3 connection be preferred. However, the problem with using the MED in this way becomes apparent with this simple example. First, AS 65100 will receive three paths to 10.1.1.0/24, one through AS 65300, and two through AS 65200. The MED of the path through AS 65100 and the paths through AS 65200 will not be compared, since their AS Path is not the same. If AS 65100 has set their BGP local preferences on router A, B, and C, to favor the path through AS 65300, then the MED from AS 65200 will have no impact, per MED is considered after local preference in the BGP decision algorithm.
NOTE
MEDs received from different autonomous systems are not compared as a default behavior, though many implementations provide a mechanism to enable comparing of MEDs between different autonomous systems. Benefits and offshoots of using MEDs, and comparing them between different ASes, will be discussed in later sections.
If the path through AS 65300 did not exist, or was not preferred over the path through AS 65200 for some other reason, the MEDs advertised by routers D and E might have some impact on the best path decision made by AS 65100. However, if AS 65100 sets some BGP metric with a higher degree of preference in the decision algorithm, such as the local preference, to prefer one path over the other, the MED would never be considered.
Local Preference
The LOCAL_PREF attribute is a well-known attribute that represents the network operator's degree of preference for a route within the entire AS. The larger the value of the local preference, the more preferable the route is; Figure 1-12 illustrates.
)
Figure
1-12: Local Preference
AS 65100 is receiving two possible paths to the 10.1.1.0/24 network, one of which is received through AS 65200, and the other of which is received through AS 65300. Although the path through AS 65200 is shorter—one AS hop rather than two—AS 65100's network administrator would prefer to send traffic destined to this prefix along the high-speed outbound OC3 connection, rather than along the outbound T1. Setting the local preference on this prefix as it is received on router A to 100, and on router B to 200, causes all of the BGP speakers within AS 65100 to prefer the path through B, thus preferring the higher speed link.
Communities
The COMMUNITIES attribute is an optional transitive attribute. Communities are, effectively, tags that can carry almost any information about a route within or between autonomous systems. Communities are used to group routes sharing common characteristics which cannot be described using the other attributes, and generally are not directly used to determine policy or the best path to a destination themselves. That is, while a community itself does not influence the BGP route selection algorithm, communities are typically used to trigger underlying policies that take effect based on the value of the associated community (e.g., communities can be used to match and modify one or more of the BGP attributes that do impact the results of the best path selection algorithm).
Several communities are defined as well known, or global, communities, which should be recognized by all BGP implementations:
The NO_EXPORT community, which states that the group of routes marked with this community should not be advertised outside of the local autonomous system.
The NO_ADVERTISE community, which states the group of routes marked with this community should not be advertised to any BGP peer of the speaker which receives it.
The NO_EXPORT_SUBCONFED community, which states the group of routes marked with this community should not be advertised outside a single autonomous system, even if that autonomous system is a part of a confederation of autonomous systems.
Communities are 32 bits (4 octets) long, with the following standards for using the community space:
The communities numbered 0x00000000 through 0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are reserved for future assignment of well known communities.
The recommended encoding for all other communities is the two-octet autonomous system number of the AS which attached the community to the route in the first two octets of the community number. The remaining two octets can be assigned based on policies internal to the AS.
NOTE
RFC1997, BGP Communities Attribute, describes communities within BGP. RFC1998, An Application of the BGP Community Attribute in Multi-home Routing, descirbes the use of the NO_EXPORT community in dual-homed environments, and the section Conditional Communities in Chapter 7 describes an extension of RFC1998.
Extended Communities
BGP Extended communities, as their name implies, are an extension to BGP communities. The primary differences between communities and extended communities are:
Extended communities are 64 bits, or 8 octets, in length.
The extended community number space is more structured than the standard community address space, as described below.
Figure 1-13 illustrates the extended community layout.
)
Figure
1-13: The Extended Community Layout
If the I bit is clear (0), the community type was assigned on a "first come, first seved" basis through the Internet Assigned Numbers Authority (IANA). If the I bit is set (1), the community type is either experimental, or was assigned through IETF consensus. If the type code indicates a sub-type (or low type) is included, the data field is 6 octets in length. If the type code indicates a sub-type is not included, the data field is 7 octets in length.
Some of the extended communities defined in various drafts include:
Autonomous System Specific (two octet), type 0x0 (or 0x4), which allows the local network administrator to carry communities specific to their autonomous system by setting the subtype to a value indicating the type of information being carried, the first two octets of the data portion to their autonomous system number, and the remaining four octets to the data carried.
Autonomous System Specific (four octet), type 0x02 (or 0x42); this extended community is similar to the AS Specific extended community above, except it allows four octets from the data field for the autonomous system number, and two octets for the data carried.
IPv4 Address Specific Type, type 0x01 or 0x41, which allows the owner of an IPv4 address block to encode some information in an extended community pertinent to this address space. The subtype field is set by the originator to indicate the type of information carried, the first four octets of the data field is set to the IPv4 address, and the last two octets of the data field are set to the pertinent information.
Opaque, type 0x03 or 0x43, allows opaque data to be carried within an extended community. The subtype field is set to a value set according to consensus within the IETF or other Internet Addressing and Number Authority (IANA) rules.
Route Target, which is a subtype of either the two octet AS specific, four octet AS specific, or IPv4 specific types, with the subtype set to 0x02. This extended community is described in further detail in Chapter 10, Deploying BGP and MPLS VPNs.
Route Origin, which is a subtype of either the two octet AS specific, four octet AS specific, or IPv4 specific types, with the subtype set to 0x03. This extended community is described in further detail in Chapter 10, Deploying BGP and MPLS VPNs.
Link Bandwidth, which is a subtype of the two octet AS specific type, with a subtype of 0x4. This community is described in more detail in Chapter 7, New Features in BGP.
NOTE
BGP extended communities are described in the in Internet-Draft document draft-ietf-idr-bgp-ext-communities, BGP Extended Communities Attribute, which should be progressed to RFC status sometime in the near future.
Multiprotocol Addresses
The original BGP packet format was formatted around IPv4 addresses, which are 4 octets in length. In order to carry new types of addresses, such as IPv6, MPLS Labels, VPN information, CLNS addresses, and others, special address family attributes were created to carry these address types. Each type of address is identified using an Address Family Identifier (AFI), and a Subsequent Address Family Identifier (SAFI). The ability of BGP to carry multiple address types is used in carrying MPLS VPN information, as described in Chapter 10, Deploying BGP and MPLS VPNs. This capability is also used to carry CLNS and IPv6 address, as described in the section Multiprotocol BGP, below.
NOTE
The ability to carry multiple address types and other information pertaining to virtual private networks, is outlined in the IETF Internet-Draft draft-ietf-idr-rfc2858bis, which is currently in draft state and species an update and intended to oboselete RFC 2858.
Attributes and Aggregation
Aggregation, or summarization, not only hides reachability information, it also hides topology information. In BGP, this means hiding the AS Path and other attributes of the prefixes aggregated.
Aggregation and the AS Path
Figure 1-14 illustrates the interaction between the AS Path and aggregation.
)
Figure
1-14: Aggregation's Impact on Route Attributes
In this network, Routers C and D are advertising 10.1.2.0/24 and 10.1.3.0/24, respectively, to Router B, which is in another autonomous system. Router B is aggregating these two advertisements towards router A, advertising the single prefix 10.1.2.0/23. But how does Router B build the AS Path in the route it advertises to router A?
It can't act as though AS65500 and AS65501 don't exist, since that would break the inherent loop detection qualities of the AS Path, and it would also break any policies based on the AS Path containing AS65500 or AS65501 in AS65503 (or downstream). It can't include both of these autonomous systems in the AS Path sequentially, since that would imply that the path to reach either of these networks passes through both of these autonomous systems.
The solution to this problem is to include both of the originating autonomous systems as an AS Set. An AS Set includes a set of autonomous systems possibly included in the path to a given advertised route, in no particular order. When advertising this aggregate, then Router B would advertise (65502 {65500, 65501}) in the AS Path, grouping AS65501 and AS65500 into an AS Set, and prepending the local AS number, AS65500.
The Atomic Aggregate
Suppose we change the network slightly, so it now looks like the network in Figure 1-15.
)
Figure
1-15: The Atomic Aggregate Bit
Suppose Router B is now receiving both 10.1.2.0/23 and 10.1.3.0/24; note these two prefixes overlap. Router B only wants to advertise 10.1.2.0/23 towards A. Since it already has this prefix in it's table, it can simply advertise the prefix as it was received from AS65500. But, this leaves out the information that part of this prefix, 10.1.3.0/24, is actually reachable in AS65501; in fact, AS65501 doesn't appear in the AS Path of the advertisement to Router A.
In this case, Router B should include the Atomic Aggregate attribute in the advertisement. This tells Router A that while the AS Path, as presented, is loop free, there is some longer prefix length component within this prefix reachable through an autonomous system not listed in the AS Path. The Atomic Aggregate is a well known discretionary attribute.