BGP Path Attribute Categories

BGP (Border Gateway Protocol) defines four categories of path attributes, as outlined in RFC 4271:

1. Well-known mandatory

   • Definition: Attributes in this category must be recognized by all BGP routers and are mandatory to be included in every BGP update message.
   • Significance: Omission of well-known mandatory attributes can lead to routing information errors, making them crucial for consistent BGP operation.
   • Example: The AS_PATH attribute is a well-known mandatory attribute.

2. Well-known discretionary

   • Definition: Attributes in this category can be recognized by all BGP routers but are included in update messages as needed.
   • Significance: Provides flexibility in BGP updates, allowing routers to include relevant information based on specific requirements.
   • Example: The COMMUNITY attribute is a well-known discretionary attribute.

3. Optional transitive

   • Definition: This category includes attributes that are transitive between Autonomous Systems (ASs). The transitive bit must be set when a BGP router advertising a route wants the attribute to be passed to other BGP routers. Even if a BGP router does not support this attribute, it can still receive routes with it and advertise them to other peers.
   • Significance: Enables the extension of BGP functionality across AS boundaries, promoting interoperability.
   • Example: The EXTENDED COMMUNITY attribute is an optional transitive attribute, and the transitive bit needs to be set when the attribute should be propagated to other routers.

4. Optional non-transitive

   • Definition: Attributes in this category are optional, and if a BGP router does not support a particular attribute, it will not advertise routes containing that attribute.
   • Significance: Allows for the introduction of non-essential information without requiring its propagation to routers that do not support it.
   • Example: The ORIGINATOR_ID attribute is an optional non-transitive attribute.

The categorization of each BGP path attribute and the setting of transitive bits are crucial for the proper functioning and interoperation of BGP routers. For a comprehensive understanding, refer to the specifics outlined in RFC 4271.

BGP path attributes:

Path Attribute Usage:

ORIGIN RFC 4271 sec. 5.1.1 (opens in a new tab)

The ORIGIN attribute is a well-known mandatory attribute that is generated by the speaker originating the associated routing information. Its value should not be changed by any other speaker.

AS_PATH RFC 4271 sec. 5.1.2 (opens in a new tab)

• The AS_PATH attribute, another well-known mandatory attribute, identifies the autonomous systems through which routing information in the UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs.

When a BGP speaker propagates a route learned from another BGP speaker, the AS_PATH attribute is modified based on the location of the receiving BGP speaker:

• When advertising to an internal peer, the AS_PATH attribute is not modified.
• When advertising to an external peer, the AS_PATH attribute is updated as follows:
  1. If the first path segment is of type AS_SEQUENCE, prepend the local system's AS number.
  2. If the first path segment is of type AS_SET, prepend a new path segment of type AS_SEQUENCE.
  3. If the AS_PATH is empty, create a new path segment of type AS_SEQUENCE with the local system's AS.

When a BGP speaker originates a route:

• For external peers, include its own AS number in an AS_SEQUENCE path segment in the AS_PATH attribute.
• For internal peers, include an empty AS_PATH attribute.

The local system may include/prepend more than one instance of its own AS number in the AS_PATH attribute, controlled via local configuration.

NEXT_HOP RFC 4271 sec. 5.1.3 (opens in a new tab)

The NEXT_HOP attribute is a well-known mandatory attribute that defines the IP address of the router to be used as the next hop for destinations listed in the UPDATE message. The calculation is as follows:

1. When sending to an internal peer:

   • If the route is not locally originated, do not modify the NEXT_HOP attribute unless configured otherwise.
   • When announcing a locally-originated route, use the interface address of the router through which the network is reachable.

2. When sending to an external peer X:

   • If the route is learned from an internal peer, use the internal peer router's interface address.
   • If learned from an external peer, use the IP address of any adjacent router known from the received NEXT_HOP attribute.
   • If the external peer shares a subnet with the announcing BGP speaker, use the interface address associated with that subnet.
   • Otherwise, use the BGP connection interface's IP address by default.

3. For multihop EBGP to an external peer X:

   • The speaker may propagate the NEXT_HOP attribute unchanged.
   • By default, use the BGP connection interface's IP address.

The NEXT_HOP attribute is chosen for the shortest available path. The BGP speaker must support disabling advertisement of third-party NEXT_HOP attributes.

A route originated by a BGP speaker should not be advertised to a peer using the peer's address as NEXT_HOP, and a route with itself as the next hop should not be installed.

The NEXT_HOP attribute helps the BGP speaker determine the outbound interface and immediate next-hop address for forwarding transit packets to associated destinations. The immediate next-hop address is determined through recursive route lookup operations in the Routing Table.

MULTI_EXIT_DISC RFC 4271 sec. 5.1.4 (opens in a new tab)

• Optional non-transitive attribute
• Used on external (inter-AS) links
• Distinguishes multiple exit/entry points to the same neighboring AS
• Value is a four-octet unsigned number (metric)
• Lower metric is preferred when other factors are equal
• If received over EBGP, can be propagated over IBGP within the same AS
• Must not be propagated to other neighboring ASes
• Mechanism (based on local configuration) to remove the attribute from a route
• Value alteration over EBGP possible based on local configuration
• Alteration must occur before determining route preference and performing route selection
• Refer to section 9.1.2.2 (opens in a new tab) for more details.

LOCAL_PREF RFC 4271 sec. 5.1.5 (opens in a new tab)

• Well-known attribute
• Included in all UPDATE messages to internal peers
• Calculates degree of preference for each external route based on locally-configured policy
• Higher degree of preference is preferred
• Used in the Decision refer to section 9.1.1 (opens in a new tab) for more details.
• Must not be included in UPDATE messages to external peers (except in BGP Confederations [RFC3065])
• If contained in an UPDATE message from an external peer, it is ignored by the receiving speaker (except in BGP Confederations [RFC3065])

ATOMIC_AGGREGATE RFC 4271 sec. 5.1.6 (opens in a new tab)

• Well-known discretionary attribute
• Used when aggregating routes for advertisement to a peer
• AS_PATH of aggregated route includes an AS_SET
• If aggregate can be safely advertised without the AS_SET and without forming route loops:
  • Include ATOMIC_AGGREGATE attribute when advertising to the peer
• Receiving BGP speaker:
  • Should not remove the attribute when propagating the route
  • Must not make any NLRI of the route more specific section 9.1.4 (opens in a new tab) when advertising to other BGP speakers
• Awareness that the actual path to destinations specified in NLRI may not be the path in the AS_PATH attribute