BGP Path Attributes

BGP path attributes are a set of parameters describing the characteristics of a BGP prefix. Because BGP is foremost a routing policy tool, BGP makes extensive use of these attributes in influencing the path selection.

  • ORIGIN
  • AS_PATH
  • NEXT_HOP
  • LOCAL_PREF
  • ATOMIC_AGGREGATE
  • AGGREGATOR
  • COMMUNITY
  • ORIGINATOR_ID
  • CLUSTER_LIST

ORIGIN

This attribute indicates a prefix’s source. There are three possible origins:

  • IGP—ORIGIN of 0

  • EGP—ORIGIN of 1

  • INCOMPLETE—ORIGIN of 3

A prefix with a lower ORIGIN value is preferred during a path selection.

A prefix’s ORIGIN attribute is automatically defined when a prefix is injected into BGP but can be modified through the use of a route map.

  • For example, if a prefix is redistributed into BGP using the redistribute command, its ORIGIN is set to 3;

  • if a prefix is injected into BGP via the network command, its origin is set to 0.

  • In effect, routes originated by thenetworkcommand are preferred over those that are redistributed.

BGP Design and Implementation

AS_PATH

AS_PATH lists in reverse order the AS traversed by a prefix, with the last AS placed at the beginning of the list.

The primary purpose of the AS_PATH is to provide loop prevention for inter-AS routing. The accepted number of AS in the list is between 1 and 255. Prepending the same AS number to the list is a common method of influencing inbound path selection, because the path with the shortest list is preferred.

Four types of AS segments within the AS_PATH are supported in Cisco IOS software:

•AS_SET
•AS_SEQUENCE
•AS_CONFED_SET
•AS_CONFED_SEQUENCE

The difference between SET and SEQUENCE is that the list of autonomous systems is unordered (with regard to the autonomous systems traversed in the path) in a SET and is ordered in a SEQUENCE. The latter two apply only to paths originated within the local confederation.

NEXT_HOP

This attribute defines the next-hop IP address to reach a prefix from the BGP point of view. This does not necessarily mean that the next hop is directly connected. If the BGP next hop is not the immediate next hop, a recursive route lookup in the IP RIB is needed. the next hop must be under a prefix in the routing table, including the 0.0.0.0/0.

BGP Design and Implementation

  • When the prefix is first injected into BGP, the next hop is set by the BGP speaker that injects the prefix depends on how the prefix is injected.

    If the prefix is injected by the aggregate-address command, the prefix’s BGP next hop is the BGP speaker doing the aggregation.

If the prefix is injected by the network command or redistribution, the IGP next hop before the injection becomes the BGP next hop. For example, if an OSPF prefix is redistributed into BGP, the BGP next hop is not necessarily the BGP speaker doing the redistribution, but rather is the original next hop of the OSPF prefix. Thus, in this case, it is advisable to reset the next hop at the redistribution point to the BGP speaker itself.

  • When the prefix is advertised via eBGP, the next hop is automatically set to the IP address of the eBGP peer that is sending the prefix.

•The next hop is manually changed through the use of a route map or next-hop-self command. Note that the next hop is not changed by default for a BGP session within the same AS.

BGP Design and Implementation

MULTI_EXIT_DISC

MED attribute is typically used on inter-AS links to discriminate among multiple exit/entry points to the same neighboring AS. . MED values are expressed as metric values.the path with a lower MED is preferred.

In Cisco IOS software, the following are some of the rules on MED setting and advertisement:

  • If a route is learned from an iBGP peer, the border router removes the MED before advertising the route to an eBGP peer. To force the border router to advertise the MED in such a case, the route-map set metric-type internal command can be configured for that eBGP peer.

  • Routes injected into BGP locally on a border router are advertised to an eBGP peer with MED. The metric values are determined as follows:

    • — If the injected BGP route, using the network or redistribute command, is from an IGP, the BGP MED is derived from the IGP metric.

    • — If the injected BGP route (using the network or redistribute command) is from a connected route, the BGP MED is set to 0.

    • — If the route is injected by the aggregate-address command, MED is not set.

    MED is sent from one AS to another neighbor AS on an eBGP link to affect the outbound policy of the receiving AS.

LOCAL_PREF

LOCAL_PREF is an attribute used by an iBGP speaker to calculate a degree of preference for each external route. It is exchanged between iBGP peers to set a preferred exit point out of an AS. The path with a higher LOCAL_PREF is preferred. This attribute is not included in eBGP prefix advertisements (typically set administratively in incoming eBGP updates) and is used only inside an AS for path selection manipulation.

COMMUNITY

A communityis defined as a group of prefixes that share a common property. Multiple communities can be applied to a prefix, each community being 4 bytes.

two types of community:

  1. well-known communities 2. private communities

    four well-known communities are supported in Cisco IOS software:

  2. NO_EXPORT—Prefixes should not be advertised to eBGP peers but can be sent to sub autonomous systems within the same confederation. The value of this community is 0xFFFFFF01.

  3. LOCAL_AS—Do not advertise these prefixes outside the local AS. With confederation, only peers within the same sub-AS are allowed to receive these prefixes. Without confederation, LOCAL_AS is treated the same as NO_EXPORT.

  4. NO_ADVERTISE—Do not advertise prefixes with this community to any peer, internal or external. The value of this community is 0xFFFFFF02.

  5. INTERNET—Advertise the prefixes to the Internet community. In other words, there are no restrictions.

ORIGINATOR_ID

ORIGINATOR_ID is used as a loop-prevention mechanism inside an AS when route reflectors (RRs) are deployed. It is created by the first RR and is not modified by subsequent RRs.

CLUSTER_LIST

CLUSTER_LIST is another loop-prevention mechanism inside an AS when RRs are deployed. This attribute records the list of CLUSTER_IDs that a prefix has traversed in an RR environment.

results matching ""

    No results matching ""