BGP Path Attributes and Best Path Selection

What Are Path Attributes?

A path attribute is the extra information BGP carries alongside a route. It lives in the Path Attributes field of the UPDATE message described in BGP Messages, and it applies to every NLRI (destination prefix) carried in that UPDATE.

This is where BGP records which ASes a route has traversed (AS_PATH), where to forward the traffic next (NEXT_HOP), and which route should be preferred (LOCAL_PREF, MED). BGP is called a path vector protocol precisely because it evaluates routes with this set of attributes rather than with a distance metric.

A single path attribute consists of flags, a type code, a length, and a value.

The Four Attribute Categories

The two high-order bits of Attribute Flags (Optional and Transitive) place each attribute in one of four categories. The category determines whether an implementation must support the attribute, and whether an attribute it does not recognize may be forwarded to the next AS.

Category	Optional	Transitive	Meaning
Well-known mandatory	0	1	Every implementation must support it, and it must be present in the UPDATE.
Well-known discretionary	0	1	Every implementation must support it, but including it in the UPDATE is optional.
Optional transitive	1	1	Support is optional. An unrecognized attribute is forwarded with the `Partial` bit set.
Optional non-transitive	1	0	Support is optional. An unrecognized attribute is discarded and not forwarded.

Well-known attributes are assumed to be understood by every BGP implementation, so their Transitive bit is always 1. The categories mainly matter for optional attributes, where the behavior on encountering an unknown attribute differs between transitive and non-transitive.

The Partial bit is used only with optional transitive attributes. A router that cannot interpret the attribute sets it to 1 when passing the attribute along, indicating that somewhere on the path a router did not recognize it.

List of Path Attributes

The main path attributes and their type codes are listed below. The number assignments are maintained in IANA’s BGP Parameters.

Type code	Attribute	Category	Description
1	`ORIGIN`	Well-known mandatory	How the route entered BGP (IGP / EGP / Incomplete). Covered in a separate article on ORIGIN.
2	`AS_PATH`	Well-known mandatory	The sequence of AS numbers the route has traversed, used for loop detection and path length comparison. Covered in a separate article on AS_PATH.
3	`NEXT_HOP`	Well-known mandatory	The next hop IP address for the route. Covered in a separate article on NEXT_HOP and in next-hop-self.
4	`MULTI_EXIT_DISC` (MED)	Optional non-transitive	Tells a neighboring AS which entry point into the local AS to prefer. Covered in a separate article on MED.
5	`LOCAL_PREF`	Well-known discretionary	Indicates which exit the local AS should prefer. Advertised to iBGP peers only. Covered in a separate article on LOCAL_PREF.
6	`ATOMIC_AGGREGATE`	Well-known discretionary	Marks an aggregate route that covers more specific routes. Covered in a separate article on route aggregation.
7	`AGGREGATOR`	Optional transitive	The AS number and Router ID of the router that performed the aggregation. Covered in a separate article on route aggregation.
8	`COMMUNITY`	Optional transitive	Tags a route so that policies can be applied to groups of routes at once. Covered in a separate article on COMMUNITY.
9	`ORIGINATOR_ID`	Optional non-transitive	The Router ID of the router that first brought the route into the AS, added by a route reflector when reflecting. Covered in Route Reflector.
10	`CLUSTER_LIST`	Optional non-transitive	The list of cluster IDs the route has traversed. Covered in Route Reflector.
14	`MP_REACH_NLRI`	Optional non-transitive	Carries routes for address families other than IPv4 unicast (RFC 4760).
15	`MP_UNREACH_NLRI`	Optional non-transitive	Withdraws routes under the same multiprotocol extension.
16	`EXTENDED COMMUNITIES`	Optional transitive	Communities extended to 8 bytes (RFC 4360).
17	`AS4_PATH`	Optional transitive	Supplements `AS_PATH` when the route passes through routers that do not support 4-octet AS numbers (RFC 6793).
18	`AS4_AGGREGATOR`	Optional transitive	Supplements `AGGREGATOR` in the same way.
32	`LARGE_COMMUNITY`	Optional transitive	12-byte communities (RFC 8092).

Between implementations built around the multiprotocol extension, such as IOS XR, even IPv4 unicast routes may be advertised inside the MP_REACH_NLRI attribute rather than in the NLRI field of the UPDATE itself. An observed example appears in BGP Messages.

WEIGHT Is Not a Path Attribute

Cisco routers have a value called WEIGHT, which is evaluated first during best path selection. It is a Cisco-specific local value, however, and it is never carried in an UPDATE message. It applies only within the router where it is configured and is not passed to neighbors.

Property	`LOCAL_PREF`	`WEIGHT`
A path attribute?	Yes (type code 5)	No (a Cisco-specific local value)
Scope	All iBGP peers (within the AS)	The configured router only
Default	100	0 (32768 for locally originated routes)
Comparison	Higher is preferred	Higher is preferred

Covered in a separate article on WEIGHT.

Best Path Selection Order

When several routes to the same prefix are learned, BGP picks exactly one as the best path, installs it in the routing table, and advertises it to its peers.

As a prerequisite, a route whose NEXT_HOP is unreachable is removed from consideration. Resolving the NEXT_HOP is the first hurdle, and an example of a route failing it appears in next-hop-self.

When several reachable routes remain, they are compared in the order below, and the comparison stops as soon as a winner emerges. The order shown is the one used by IOS XR. The IOS XE column indicates whether IOS XE behaves the same way at that step.

Step	Comparison	Preferred	IOS XE
1	`WEIGHT`	Higher	Same
2	`LOCAL_PREF`	Higher	Same
3	Locally originated	Originated by `network` / `redistribute` / aggregation	Same
4	`AS_PATH` length	Shorter	Same
5	`ORIGIN`	IGP < EGP < Incomplete	Same
6	`MULTI_EXIT_DISC`	Lower (compared only among routes from the same neighboring AS)	Same
7	eBGP versus iBGP	The route learned over eBGP	Same
8	IGP metric to the `NEXT_HOP`	Lower	Same
9	Age of the route	Older (for eBGP routes)	Same
10	BGP Router ID	Lower (the `ORIGINATOR_ID` if present)	Same
11	`CLUSTER_LIST` length	Shorter	Same
12	Neighbor IP address	Lower	Same

IOS XR and IOS XE do not differ in this order. What differs is the name of the optional commands that change how the comparison behaves.

Behavior	IOS XR	IOS XE
Compare MED even between routes from different neighboring ASes	`bgp bestpath med always`	`bgp always-compare-med`
Do not compare `AS_PATH` length	`bgp bestpath as-path ignore`	`bgp bestpath as-path ignore`
Always compare Router ID on a tie	`bgp bestpath compare-routerid`	`bgp bestpath compare-routerid`

Verification on Real Devices

Five IOS XR (XRd) routers are used to check which flags each path attribute carries inside an UPDATE message. The topology is the same one used in Route Reflector: iBGP inside AS 65001 with R2 as the route reflector, and eBGP between the ASes.

As it stands, no optional transitive attribute would appear, so R3 attaches a COMMUNITY in its outbound route policy toward the eBGP peer.

Attaching a COMMUNITY on R3
route-policy SET-COMM
  set community (65001:100)
  pass
end-policy
!
router bgp 65001
 neighbor 10.3.4.4
  remote-as 65002
  address-family ipv4 unicast
   send-community-ebgp
   route-policy PASS-ALL in
   route-policy SET-COMM out
  !
 !
!

On IOS XR, send-community-ebgp is required to send COMMUNITY to an eBGP peer (on IOS XE it is neighbor <address> send-community). Without it, a community attached by a route policy never reaches the peer. This is a sending control on the implementation side, separate from the transitivity of the attribute itself.

Attributes Observed in an iBGP UPDATE

A capture was taken between R1 and R2 (iBGP) to look at the UPDATE in which R2 advertises 192.168.3.0/24 to R1. It is packet No.22 of the attached iBGP capture (bgp-path-attributes-ibgp.pcap), a TCP segment carrying three UPDATEs; the one shown below is the UPDATE that advertises 192.168.3.0/24. The bit-level breakdown of each flag byte is elided with <snip>.

Download just this No.22 (bgp-path-attributes-ibgp-no22.pcap)

R2 -> R1 UPDATE (192.168.3.0/24, iBGP)
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 75
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 52
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.3
                IPv4 Address: 10.0.0.3
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: empty
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 0
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100
        Path Attribute - CLUSTER_LIST: 10.0.0.2
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: CLUSTER_LIST (10)
            Length: 4
            Cluster List: 10.0.0.2
                Cluster ID: 10.0.0.2
        Path Attribute - ORIGINATOR_ID: 10.0.0.3
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: ORIGINATOR_ID (9)
            Length: 4
            Originator identifier: 10.0.0.3

Well-known attributes carry 0x40 (Transitive, Well-known) and optional non-transitive attributes carry 0x80 (Optional, Non-transitive). LOCAL_PREF is well-known discretionary, so its flags are the same 0x40 as the other well-known attributes; what sets it apart from ORIGIN and AS_PATH is that it is advertised to iBGP peers only.

Attributes Observed in an eBGP UPDATE

A capture was taken between R3 and R4 (eBGP) to look at the UPDATE in which R3 advertises 192.168.3.0/24 to R4. It is packet No.21 of the eBGP capture (bgp-path-attributes-ebgp.pcap), a TCP segment carrying four UPDATEs.

Download just this No.21 (bgp-path-attributes-ebgp-no21.pcap)

R3 -> R4 UPDATE (192.168.3.0/24, eBGP)
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 67
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 44
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.3.4.3
                IPv4 Address: 10.3.4.3
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.3.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.3.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65001
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0
        Path Attribute - COMMUNITIES: 65001:100
            Flags: 0xc0, Optional, Transitive, Complete
<snip>
            Type Code: COMMUNITIES (8)
            Length: 4
            Communities: 65001:100
                Community: 65001:100
                    Community AS: 65001
                    Community value: 100

The flags on COMMUNITIES are 0xc0 (Optional, Transitive). Note also that LOCAL_PREF is absent from this UPDATE: being well-known discretionary and meaningful only within an AS, it is not sent to eBGP peers. ORIGINATOR_ID and CLUSTER_LIST likewise never cross an AS boundary.

All four categories have now been observed in real packets.

Category	Flags	Attributes observed here	Link
Well-known mandatory	`0x40`	`ORIGIN`, `AS_PATH`	Both iBGP and eBGP
Well-known discretionary	`0x40`	`LOCAL_PREF`	iBGP only
Optional transitive	`0xc0`	`COMMUNITIES`	eBGP
Optional non-transitive	`0x80`	`MULTI_EXIT_DISC`, `ORIGINATOR_ID`, `CLUSTER_LIST`	iBGP (MED also seen on eBGP)

The flags on MP_REACH_NLRI are 0x90. That is 0x80 (Optional, Non-transitive) plus 0x10 (Extended Length), indicating that the attribute length field is two bytes.

Confirming Transitivity on Real Devices

To confirm that COMMUNITY is optional transitive, the route is followed across two AS boundaries. Only R3, in AS 65001, attaches the community.

First, what R4 (AS 65002) received:

R4 show bgp 192.168.3.0/24
RP/0/RP0/CPU0:R4#show bgp 192.168.3.0/24

BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 14           14
Last Modified: Sep  5 08:09:28.774 for 00:02:53
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.4.5.5        10.3.4.3
  Path #1: Received by speaker 0
  65001
    10.3.4.3 from 10.3.4.3 (10.0.0.3)
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best
      Community: 65001:100
      Origin-AS validity: (disabled)

Adding send-community-ebgp on R4 toward R5 as well carries the same value on to R5 in AS 65003.

R5 show bgp 192.168.3.0/24
RP/0/RP0/CPU0:R5#show bgp 192.168.3.0/24

BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 14           14
Last Modified: Sep  5 08:11:52.774 for 00:00:05
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  65002 65001
    10.4.5.4 from 10.4.5.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, best, group-best
      Community: 65001:100
      Origin-AS validity: (disabled)

The COMMUNITY attached in AS 65001 has been carried through AS 65002 and into AS 65003. The ORIGINATOR_ID and CLUSTER_LIST that appeared in the same UPDATE (optional non-transitive) never left AS 65001. That is the difference between transitive and non-transitive.

The full captures are available here.

Download the full iBGP capture (bgp-path-attributes-ibgp.pcap)

Download the full eBGP capture (bgp-path-attributes-ebgp.pcap)

Verification Configs

The configurations of R3 and R4, which carry the COMMUNITY settings. R1, R2 and R5 are the same as the verification configs in Route Reflector.

Download R3 config (r3_bgp-path-attributes.cfg)

Download R4 config (r4_bgp-path-attributes.cfg)

References

Document	Title	Description
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Defines the four attribute categories, the well-known attributes, and the basic route selection rules.
RFC 1997	BGP Communities Attribute	Defines the `COMMUNITY` attribute.
RFC 4360	BGP Extended Communities Attribute	Defines the `EXTENDED COMMUNITIES` attribute.
RFC 4456	BGP Route Reflection	Defines `ORIGINATOR_ID` and `CLUSTER_LIST`.
RFC 4760	Multiprotocol Extensions for BGP-4	Defines `MP_REACH_NLRI` and `MP_UNREACH_NLRI`.
RFC 6793	BGP Support for Four-Octet AS Number Space	Defines `AS4_PATH` and `AS4_AGGREGATOR`.
RFC 8092	BGP Large Communities Attribute	Defines the `LARGE_COMMUNITY` attribute.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used by BGP, including path attribute type codes.