BGP Path Attributes: How Two Bits in the Flags Byte Explain Most of BGP

BGP does not carry routes. It carries prefixes with attributes attached, and every interesting property of BGP — policy, loop prevention, path selection, route reflection, multiprotocol support — is implemented as an attribute rather than as protocol logic. That design is why BGP has been extended for twenty-five years without a version change: adding a capability means defining a new attribute type code, and routers that do not understand it either pass it along or drop it according to two bits in its flags field. Understanding those two bits, and the four categories they produce, explains more about BGP behaviour than any amount of memorising the path selection order.

The four categories are not arbitrary labels. Well-known mandatory attributes — ORIGIN, AS_PATH, NEXT_HOP — must appear in every UPDATE and every implementation must recognise them; a missing one is a protocol error that resets the session. Well-known discretionary attributes, LOCAL_PREF and ATOMIC_AGGREGATE, must be recognised but need not be present. Optional transitive attributes such as COMMUNITY may be unrecognised, in which case a router forwards them untouched and sets a partial bit to record that it did so. Optional non-transitive attributes — MED, ORIGINATOR_ID, CLUSTER_LIST — are silently discarded by any router that does not understand them, which is precisely why MED does not propagate beyond one autonomous system.

This article works through the attribute system from the encoding upward. Section one covers the flags, type codes, and the four categories they define. Section two covers the three mandatory attributes and the rules that govern each, including the NEXT_HOP behaviours that generate most iBGP problems. Section three covers the discretionary and optional attributes that drive path selection. Section four is communities — standard, extended, and large — and how they are actually used to signal policy between autonomous systems. Section five is the failure catalogue.

How Are BGP Path Attributes Classified and Encoded?

What do the flag bits actually control?

Each attribute begins with a one-byte flags field. The high-order bit is the Optional bit: zero means well-known and every conformant implementation must recognise it, one means optional. The next bit is Transitive: for an optional attribute, one means a router that does not recognise it should forward it unchanged, zero means it should discard it. Well-known attributes must always have the transitive bit set. The third bit is Partial, set by a router that forwarded an optional transitive attribute it did not recognise. The fourth is Extended Length, which switches the length field from one byte to two. The remaining four bits are unused and must be zero.

A Deeper Dive into Encoding and Categories

The type codes worth knowing

Why the transitive bit is the important one

The transitive bit is what allowed BGP to be extended without breaking the internet. When RFC 1997 defined communities in 1996, routers that had never heard of type code 8 were already deployed everywhere. Because the attribute is optional transitive, those routers forwarded it untouched — setting the partial bit to record that they had passed on something they did not understand — and the attribute reached its destination intact. Every subsequent extension has used the same mechanism.

The inverse case is equally deliberate. MED is optional non-transitive, so a router that does not understand it drops it. But even routers that do understand it do not propagate it to an external peer by default, because the attribute is defined as meaningful only between two directly adjacent autonomous systems. Non-transitive is the encoding; the one-AS-hop scope is the semantics that encoding was chosen to express.

! Read the flags off the wire with a capture
R1# show ip bgp 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 17
Paths: (1 available, best #1, table default)
  65001 65010
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 65001:100 65001:2000
      rx pathid: 0, tx pathid: 0x0
! IOS decodes attributes rather than showing raw flags. To see the
! flags byte itself, capture and decode the UPDATE:
R1# monitor capture CAP interface GigabitEthernet0/1 both
R1# monitor capture CAP match ipv4 protocol tcp any eq 179 any
R1# monitor capture CAP start

What happens when a mandatory attribute is missing

An UPDATE lacking ORIGIN, AS_PATH, or NEXT_HOP is a protocol error. The receiving router sends a NOTIFICATION with an UPDATE Message Error code and tears down the session. This is deliberately harsh — a malformed UPDATE could poison the routing table — and it is why the three mandatory attributes are the only ones whose absence can drop a BGP session rather than merely affecting a path.

! A malformed UPDATE resets the session with a specific code
%BGP-3-NOTIFICATION: sent to neighbor 192.0.2.2 3/1 (update malformed)
 6 bytes 0104 0000
! ^ Error code 3 = UPDATE Message Error
!   Subcode 1 = Malformed Attribute List
!   Subcode 3 = Missing Well-known Attribute
!
! Modern implementations can withdraw the prefix instead of resetting
router bgp 65000
 address-family ipv4 unicast
  bgp bestpath aigp ignore
 ! Attribute error handling per RFC 7606 is on by default on IOS-XE:
 ! treat-as-withdraw rather than session reset for many error classes.

What Do the Well-Known Mandatory Attributes Do?

What rules govern ORIGIN, AS_PATH and NEXT_HOP?

ORIGIN records how the prefix entered BGP: IGP for a network statement, EGP for the obsolete predecessor protocol, and INCOMPLETE for anything redistributed. AS_PATH is a list of segments recording every autonomous system the update traversed; a router that sees its own AS number in a received AS_PATH discards the update, which is BGP's loop prevention. NEXT_HOP is the address to forward toward, and its handling differs sharply between eBGP and iBGP: a router advertising to an external peer sets it to its own address, while a router advertising to an internal peer leaves it unchanged. That last rule is the origin of most iBGP reachability problems.

A Deeper Dive into the Three Mandatory Attributes

ORIGIN and why redistributed routes lose

ORIGIN takes three values and lower is preferred: IGP (0), EGP (1), INCOMPLETE (2). A prefix advertised with a network statement carries IGP; one redistributed from an IGP carries INCOMPLETE. Because ORIGIN is step five in the best-path algorithm, two otherwise identical paths where one was originated by network and the other by redistribution will always select the network one. This surprises people during migrations where the same prefix is originated two different ways at two different sites.

! network statement -> Origin IGP (i)
router bgp 65000
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
!
! redistribution -> Origin incomplete (?)
router bgp 65000
 address-family ipv4 unicast
  redistribute ospf 1
!
R1# show ip bgp | include 203.0.113
 *> 203.0.113.0/24   10.0.0.1     0    32768 i
 *  203.0.113.0/24   10.0.0.5     0    32768 ?
! ^ The trailing character is the ORIGIN. 'i' beats '?' at step 5.
!
! Override it explicitly if the difference is unwanted
route-map SET-ORIGIN permit 10
 set origin igp

AS_PATH segments and what counts as length

AS_PATH is not a flat list. It is a sequence of segments, each with a type and a set of AS numbers. AS_SEQUENCE is the ordinary ordered list and each AS in it counts as one toward path length. AS_SET, produced by aggregation that merges paths from multiple sources, counts as exactly one regardless of how many AS numbers it contains. AS_CONFED_SEQUENCE and AS_CONFED_SET, used inside confederations, count as zero — which is what makes a confederation's internal structure invisible to path-length comparison outside it.

! An aggregate that produces an AS_SET
router bgp 65000
 address-family ipv4 unicast
  aggregate-address 10.0.0.0 255.0.0.0 as-set
!
R1# show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 42
  {65001,65002,65003}, (aggregated by 65000 1.1.1.1)
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best
! ^ Braces denote an AS_SET. Three AS numbers, path length 1.
!
! Without as-set, the aggregate loses path information entirely
! and carries ATOMIC_AGGREGATE instead
R1# show ip bgp 10.0.0.0/8 | include atomic
      Origin IGP, localpref 100, weight 32768, valid, atomic-aggregate, best

AS_PATH as loop prevention, and when you must defeat it

A router receiving an update whose AS_PATH already contains its own AS number discards it. That is correct almost always, and wrong in two specific designs: a customer with two sites that share an AS number and connect through a provider, and an MPLS L3VPN where a customer uses the same AS at multiple sites. Two commands address these, and both weaken loop prevention deliberately.

! The customer side: accept routes containing my own AS number
router bgp 65100
 address-family ipv4 unicast
  neighbor 192.0.2.1 allowas-in 3
  ! Accept up to 3 occurrences of 65100 in the AS_PATH
!
! The provider side: present a different AS to this customer
router bgp 65000
 address-family ipv4 unicast vrf CUST-A
  neighbor 172.16.1.2 remote-as 65100
  neighbor 172.16.1.2 local-as 65200
  ! The customer sees 65200; the real AS is prepended behind it
!
! Strip private AS numbers before advertising to the internet
  neighbor 192.0.2.6 remove-private-as all

NEXT_HOP: three rules and one exception

Advertising to an eBGP peer sets NEXT_HOP to the advertising router's own interface address on the shared link. Advertising to an iBGP peer leaves NEXT_HOP unchanged, so an internally propagated external prefix retains the external peer's address — which the internal routers may have no route to. Redistributing a route into BGP sets NEXT_HOP to the next hop from the source protocol. The exception applies on a shared multi-access segment: if the advertising router's own next hop for the prefix is on the same subnet as the eBGP peer it is advertising to, it may preserve that address rather than substituting its own, producing a third-party next hop.

! The classic iBGP problem: unresolvable next hop
R5# show ip bgp 203.0.113.0
Paths: (1 available, no best path)
  65001
    198.51.100.1 (inaccessible) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal
! ^ 198.51.100.1 is the eBGP peer's address, carried unchanged
!   through iBGP. R5 has no route to it, so no best path is elected.
!
! Fix 1 (usual): rewrite the next hop at the border
router bgp 65000
 address-family ipv4 unicast
  neighbor 10.0.0.5 next-hop-self
  ! 'next-hop-self all' also rewrites for reflected routes
!
! Fix 2: carry the eBGP link in the IGP as a passive interface
router ospf 1
 passive-interface GigabitEthernet0/0
 network 198.51.100.0 0.0.0.255 area 0

How Do the Discretionary and Optional Attributes Change Path Selection?

Which attributes influence the decision and at which step?

Weight, which is Cisco-proprietary and not an attribute at all, decides at step one and never leaves the router. LOCAL_PREF decides at step two and propagates through the entire AS including confederation sub-autonomous systems, but is stripped before advertising to a true external peer. AS_PATH length decides at step four. ORIGIN at step five. MED at step six, and only between paths whose leftmost AS is identical. ORIGINATOR_ID substitutes for the router ID at step eleven, and CLUSTER_LIST length decides at step twelve. Everything else in the attribute set — communities, aggregator, atomic aggregate — carries information but participates in no comparison.

A Deeper Dive into the Selection-Relevant Attributes

LOCAL_PREF and its scope

LOCAL_PREF is a 32-bit value defaulting to 100 on Cisco platforms. It is well-known discretionary, which means every implementation recognises it but it need not be present — and by rule it is included only in updates sent to internal peers. A router that receives a prefix from an external peer with no LOCAL_PREF assigns the local default before propagating it internally. This scoping is exactly what makes it the correct instrument for expressing an AS-wide exit preference.

! Set at ingress, honoured by every router in the AS
route-map PREFER-TRANSIT-A permit 10
 match as-path 10
 set local-preference 200
route-map PREFER-TRANSIT-A permit 20
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map PREFER-TRANSIT-A in
  ! Change the AS-wide default if 100 is inconvenient
  bgp default local-preference 100

MED, and the two things that make it awkward

MED is optional non-transitive, so it does not propagate beyond the AS that received it. Within the best-path algorithm it is compared only between paths whose leftmost AS in the AS_PATH is the same — that is, paths learned from the same neighbouring autonomous system. Two paths from different providers are not MED-comparable no matter what values they carry, and step six is skipped entirely for them. Cisco treats a missing MED as zero, the most preferred value, unless bgp bestpath med missing-as-worst is configured.

! Signal a preferred entry point to one neighbouring AS
route-map MED-PRIMARY permit 10
 set metric 50
route-map MED-BACKUP permit 10
 set metric 200
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 192.0.2.2 route-map MED-PRIMARY out
  neighbor 192.0.2.10 route-map MED-BACKUP out
! ^ Only meaningful if both neighbours are in the SAME AS.
!
! Remove the order-dependence that non-comparability creates
router bgp 65000
 bgp deterministic-med
 ! And optionally treat an absent MED as worst rather than best
 bgp bestpath med missing-as-worst

ATOMIC_AGGREGATE and AGGREGATOR

When a router aggregates prefixes and the resulting summary does not carry the AS_PATH information of its components, it sets ATOMIC_AGGREGATE to record that detail was lost. A downstream router receiving an atomic aggregate must not de-aggregate it or make assumptions about the more specific prefixes behind it. AGGREGATOR accompanies it, recording the AS number and router ID that performed the aggregation — which is genuinely useful for tracing where an unexpected summary originated.

R5# show ip bgp 10.0.0.0/8
BGP routing table entry for 10.0.0.0/8, version 88
Paths: (1 available, best #1, table default)
  65000
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
      Origin IGP, localpref 100, valid, external, atomic-aggregate, best
      Aggregator 65000 1.1.1.1
! ^ Router 1.1.1.1 in AS 65000 created this summary. If the summary
!   is unexpected, that is where to go and look.

ORIGINATOR_ID and CLUSTER_LIST

Both exist for route reflection. A reflector sets ORIGINATOR_ID to the router ID of the client that originated the route, and any router seeing its own router ID there discards the update — the reflection equivalent of AS_PATH loop detection. CLUSTER_LIST records each reflection cluster the update has passed through; a reflector seeing its own cluster ID discards the update. Both are optional non-transitive, so they never leave the AS.

RR-CLIENT# show ip bgp 203.0.113.0/24
  65001
    10.0.0.1 from 10.0.0.9 (10.0.0.9)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.0.0.1, Cluster list: 10.0.0.9
! ^ Originated by 10.0.0.1, reflected by the RR with cluster ID
!   10.0.0.9. Step 11 uses the Originator, not the advertising router.
!
! Cluster ID defaults to the RR's router ID; set it explicitly when
! two RRs serve the same clients as a redundant pair
router bgp 65000
 bgp cluster-id 10.0.0.9

How Do Communities Actually Get Used?

What are the three community types and when do you need each?

Standard communities, defined in RFC 1997, are 32-bit values conventionally written as AS:VALUE — sixteen bits of autonomous system and sixteen bits of local meaning. Extended communities, RFC 4360, are 8 bytes with a type and subtype field, which gives them structure; Route Target and Route Origin in MPLS L3VPN are extended communities, as are the OSPF Domain ID and Route Type values used in PE-CE OSPF. Large communities, RFC 8092, are 12 bytes structured as three 4-byte fields, which exists because a 4-byte autonomous system number does not fit in the 16-bit AS field of a standard community. On Cisco platforms none of the three is advertised unless send-community is configured for the neighbour.

A Deeper Dive into Communities

The well-known standard communities

! Tag a more-specific so it never leaves the AS
ip community-list standard KEEP-INSIDE permit no-export
!
route-map TAG-SPECIFICS permit 10
 match ip address prefix-list MORE-SPECIFICS
 set community no-export
route-map TAG-SPECIFICS permit 20
!
router bgp 65000
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.128 route-map TAG-SPECIFICS
  ! Communities are NOT sent unless you say so
  neighbor 10.0.0.5 send-community both

The send-community requirement

Cisco does not advertise communities to a neighbour by default. A route-map that sets a community will happily set it, the local router will display it, and the neighbour will receive an update with no community attached. The keyword takes standard, extended, or both, and forgetting the extended variant on a VPNv4 session breaks route target propagation entirely — which is why VPNv4 templates always include it.

! Standard communities only
neighbor 10.0.0.5 send-community
! Extended only - what a VPNv4 session needs for route targets
neighbor 10.0.0.5 send-community extended
! Both, which is what you almost always want
neighbor 10.0.0.5 send-community both
!
! Verify what the neighbour actually receives
R1# show ip bgp neighbors 10.0.0.5 advertised-routes
R5# show ip bgp 203.0.113.0/24 | include Community
      Community: 65000:100 no-export
! ^ Absent here but present on R1 means send-community is missing.

Additive versus replacing

set community replaces every community already on the route. set community ... additive appends. This is the community equivalent of the switchport trunk allowed vlan trap: a route-map that tags prefixes with your own community and does not say additive silently strips whatever an upstream provider attached, which may include the signalling that made their side behave correctly.

! REPLACES all existing communities - usually not what you want
route-map TAG permit 10
 set community 65000:100
!
! APPENDS, preserving what upstream attached
route-map TAG permit 10
 set community 65000:100 additive
!
! Deliberately clear everything, then set your own
route-map CLEAN permit 10
 set community none
route-map CLEAN permit 20
 set community 65000:100 additive

Provider communities and why they beat prepending

AS_PATH prepending is a request: it lengthens your path and hopes the other AS compares path length. It fails whenever the other AS sets local preference at ingress, because local preference decides at step two and path length at step four. Most transit providers publish communities that let a customer set local preference inside the provider's network directly — which is an instruction rather than a request, and works regardless of what the provider's own policy does at step two.

! Provider-published community to lower local pref inside their AS
route-map DEPREF-VIA-TRANSIT-B permit 10
 ! Example format only - every provider publishes its own values
 set community 65002:80 additive
!
router bgp 65000
 address-family ipv4 unicast
  neighbor 192.0.2.6 route-map DEPREF-VIA-TRANSIT-B out
  neighbor 192.0.2.6 send-community
!
! Compare with prepending, which the provider may simply ignore
route-map PREPEND permit 10
 set as-path prepend 65000 65000 65000

Extended and large communities

! Extended community: Route Target in an MPLS L3VPN
vrf definition CUST-A
 rd 65000:100
 address-family ipv4
  route-target export 65000:100
  route-target import 65000:100
 exit-address-family
!
! Site of Origin, to stop a route returning to the site it came from
route-map SET-SOO permit 10
 set extcommunity soo 65000:1
!
! Large community: three 4-byte fields, for 4-byte ASNs
route-map TAG-LARGE permit 10
 set large-community 4200000000:100:1 additive
!
! Match on them with the corresponding list types
ip extcommunity-list standard RT-CUSTA permit rt 65000:100
ip large-community-list standard LC-TAG permit 4200000000:100:1

Which Attribute Behaviours Cause Production Problems?

What goes wrong most often?

Six things. NEXT_HOP unchanged across iBGP leaves prefixes unresolvable. Communities are never sent because send-community is missing. set community without additive strips a peer's tags. MED is expected to influence a decision between two different providers, where it is never compared. A 4-byte AS number appears as 23456 on a legacy peer. And an optional transitive attribute nobody recognises propagates across the network with the partial bit set, appearing in captures and confusing everyone who sees it.

A Deeper Dive into the Failure Catalogue

The 4-byte ASN transition and AS_TRANS

AS_PATH's original encoding used 2-byte AS numbers. RFC 6793 introduced 4-byte support with a compatibility mechanism: a router that does not support 4-byte ASNs sees the reserved value 23456, called AS_TRANS, in place of every 4-byte number, while the real values travel in the optional transitive AS4_PATH attribute alongside. A 4-byte-capable router reconstructs the true path by merging the two. Seeing 23456 in an AS_PATH means a legacy speaker is somewhere in the path, not that anything is broken.

! What a 2-byte-only router sees
R-OLD# show ip bgp 203.0.113.0/24
  23456 23456 65010
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
!
! What a 4-byte-capable router sees for the same prefix
R-NEW# show ip bgp 203.0.113.0/24
  4200000001 4200000002 65010
    192.0.2.2 from 192.0.2.2 (192.0.2.2)
!
! Confirm the capability was negotiated on the session
R1# show ip bgp neighbors 192.0.2.2 | include Four-octet
    Four-octets ASN Capability: advertised and received

The partial bit in the wild

An optional transitive attribute passing through a router that does not recognise it arrives with the partial bit set. This is normal and harmless, and it is the mechanism that let communities and route targets deploy incrementally. It becomes a diagnostic when an attribute you expect to be understood arrives partial — that tells you a router in the path is older or is running a code version without support for it.

Attribute filtering, deliberate and accidental

Several commands remove attributes, and each has a legitimate use and an accidental one. remove-private-as strips private AS numbers from AS_PATH before advertisement. set community none clears communities. A route-map that omits additive clears them by accident. And a peer-group or template applied to the wrong neighbour can strip attributes on a session where they mattered.

! Audit what a specific neighbour is actually receiving
R1# show ip bgp neighbors 192.0.2.6 advertised-routes
!
! ...and what a specific neighbour sent before your policy ran
R1# show ip bgp neighbors 192.0.2.2 received-routes
! ^ Requires 'neighbor 192.0.2.2 soft-reconfiguration inbound',
!   which costs memory proportional to the table size.
!
! Compare against the post-policy view
R1# show ip bgp neighbors 192.0.2.2 routes

Conclusion

BGP is a database replication protocol with an attribute system bolted to the front, and almost every question about its behaviour is really a question about one attribute's category. Whether something propagates across an autonomous system boundary is the transitive bit. Whether an old router will pass it along or drop it is the same bit. Whether its absence is a protocol error or merely a missing preference is the optional bit. Learning the four categories and which attributes fall into each replaces a large amount of memorisation with two yes-or-no questions.

The three mandatory attributes deserve particular attention because they carry the behaviours that generate the most operational work. ORIGIN quietly decides between two otherwise identical paths at step five, which is why a prefix originated by network at one site and by redistribution at another does not behave symmetrically. AS_PATH is both a loop-prevention mechanism and a comparison input, and the two purposes conflict in exactly the designs — multi-site customers sharing an AS — where allowas-in and local-as become necessary. NEXT_HOP is unchanged across iBGP by specification, which makes next-hop-self an architectural decision rather than a fix.

Communities are worth a final note because they are the most-used attribute that participates in no comparison at all. They do nothing until a route-map somewhere matches them, which means every community-based traffic engineering scheme is an agreement between two parties rather than a capability of the protocol. On Cisco platforms they are also not transmitted unless send-community is configured, and they are silently replaced rather than appended unless additive is present. Those two omissions account for a remarkable proportion of BGP policy that appears configured and does nothing. Build a four-AS lab, set each attribute in turn, and watch which ones survive each boundary — the pattern of what disappears where is the attribute system made visible.

Reference Notes

1. RFC 4271, Section 4.3 — the path attribute encoding: attribute flags, type code, length, and value.
2. RFC 4271, Section 4.3 — the flags byte: Optional bit, Transitive bit, Partial bit, and Extended Length bit, with the remaining four bits unused.
3. RFC 4271, Section 5 — the four attribute categories: well-known mandatory, well-known discretionary, optional transitive, and optional non-transitive.
4. RFC 4271, Section 5.1.1 — ORIGIN values IGP (0), EGP (1), and INCOMPLETE (2), and their ordering in path selection.
5. RFC 4271, Section 5.1.2 — AS_PATH segment types AS_SET and AS_SEQUENCE, and the loop-detection rule based on the local AS number.
6. RFC 4271, Section 5.1.3 — NEXT_HOP semantics, including the rule that it is not modified when advertising to an internal peer.
7. RFC 4271, Section 5.1.4 — MULTI_EXIT_DISC as an optional non-transitive attribute compared only between routes from the same neighbouring AS.
8. RFC 4271, Section 5.1.5 — LOCAL_PREF is included only in UPDATE messages sent to internal peers.
9. RFC 4271, Section 5.1.6 and 5.1.7 — ATOMIC_AGGREGATE and AGGREGATOR, and the restriction on de-aggregating an atomic aggregate.
10. RFC 1997 — the COMMUNITY attribute and the well-known values 0xFFFFFF01, 0xFFFFFF02, and 0xFFFFFF03.
11. RFC 4456, Section 7 — ORIGINATOR_ID and CLUSTER_LIST, and their use in route reflection loop prevention.
12. RFC 6793, Section 3 — AS_TRANS (23456) and the AS4_PATH attribute used during the 4-byte AS number transition.