Home > Articles > Networking

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 8Figure 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 9Figure 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 10Figure 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 11Figure 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 12Figure 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 13Figure 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 14Figure 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 15Figure 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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020