Day 9 — BGP Path-Attribute Taxonomy: Mandatory, Discretionary, Transitive and Non-Transitive

Learning objective

Classify BGP path attributes by well-known/optional and transitive/non-transitive behavior, interpret the purpose of attribute flags, and use observed attributes to reason about propagation without confusing attribute presence with best-path preference.

BGP Path-Attribute Taxonomy

---

1. Opening — BGP advertises a destination and a story about how to reach it

A prefix by itself says almost nothing about routing policy.

The operational value of BGP comes from the information attached to reachability. AS_PATH can reveal the sequence of autonomous systems. NEXT_HOP tells the receiver what forwarding resolution must succeed. ORIGIN records how the route entered BGP in the standardized origin model. LOCAL_PREF can influence exit selection inside an AS. Communities can carry policy tags. Aggregation can add other attributes.

These values are not all treated the same way. Some must be understood by every BGP implementation. Some are optional. Some can cross AS boundaries even when an intermediate system does not understand them. Others are intentionally local to a narrower scope.

Before manipulating attributes, engineers need to understand their taxonomy.

---

2. The four RFC 4271 categories

RFC 4271 groups path attributes into four categories:

1. Well-known mandatory
2. Well-known discretionary
3. Optional transitive
4. Optional non-transitive

This classification answers two questions:

• Must every conforming BGP implementation recognize the attribute?
• If the attribute is optional, should an implementation that does not recognize it still propagate it?

Those are protocol questions. They are not the same as “is this attribute important?” or “does this attribute affect best path?”

---

3. Well-known mandatory attributes

Well-known attributes must be recognized by BGP implementations. Mandatory attributes must appear when required for the type of UPDATE being advertised.

For the base IPv4-unicast model, the classic well-known mandatory attributes are:

• ORIGIN
• AS_PATH
• NEXT_HOP

ORIGIN

The standardized ORIGIN values are IGP, EGP and INCOMPLETE. The names are historical and should not be confused with the entire modern route-source story.

AS_PATH

AS_PATH records autonomous-system path information and supports loop prevention as well as policy decisions.

NEXT_HOP

NEXT_HOP identifies the forwarding next hop associated with the advertised path in the relevant base behavior. Its reachability is critical; a path with an unresolved next hop cannot simply be treated as usable forwarding information.

Each receives deeper coverage later.

---

4. Well-known discretionary attributes

Well-known discretionary attributes must be understood by BGP implementations but are not required to appear in every UPDATE.

Important examples in RFC 4271 include:

• LOCAL_PREF
• ATOMIC_AGGREGATE

LOCAL_PREF is normally significant within an autonomous system and is used for policy preference among internal BGP speakers. ATOMIC_AGGREGATE relates to loss of path-detail during aggregation and is covered with aggregation on Day 11.

The word discretionary does not mean unimportant. It describes whether the attribute must be present in every applicable route advertisement.

---

5. Optional transitive attributes

Optional attributes are not required to be recognized by every BGP implementation.

A transitive optional attribute is designed to be carried onward across BGP speakers even when a speaker does not fully understand the attribute, subject to the protocol rules.

Examples include:

• AGGREGATOR;
• the standard COMMUNITIES attribute defined by RFC 1997;
• several later extensions designed to preserve policy or metadata across AS boundaries.

This behavior supports extensibility. New attributes can be introduced without requiring every intermediate BGP implementation to understand their semantics before the information can traverse the network.

That extensibility also increases the importance of robust error handling, which is one reason RFC 7606 matters.

---

6. Optional non-transitive attributes

An optional non-transitive attribute is not required to be propagated by a BGP speaker that does not recognize it.

A well-known example is:

• MULTI_EXIT_DISC (MED)

MED can influence how one AS signals a preference to another for entering through different links, but its comparison rules and operational scope are nuanced. It will receive dedicated coverage later rather than being treated as “smaller always wins everywhere.”

---

7. Attribute flags: the wire carries behavior hints

Each path attribute includes flags that describe properties of the attribute. In the RFC 4271 encoding, important flag concepts include:

• Optional
• Transitive
• Partial
• Extended Length

The Optional and Transitive bits align with the classification model.

The Partial bit is relevant to optional transitive information and can indicate that an attribute has been passed along without complete recognition/processing in the path. The detailed rules matter when implementing or decoding BGP, but the operator's key lesson is that an attribute header carries protocol-behavior metadata, not just a type number and value.

The Extended Length flag allows a larger length field when an attribute value exceeds the one-octet-length encoding range.

Packet analysis tools decode these flags, but engineers should still understand what the decoder is representing.

---

8. Attribute category does not equal best-path order

A common learning mistake is to mix two separate frameworks:

Attribute classification

Answers questions such as:

• Is the attribute mandatory?
• Is it recognized by all BGP implementations?
• Is it transitive?

Best-path selection

Answers:

• Which candidate path does this implementation prefer?

An optional transitive community might be operationally critical but not directly be a native step in best-path selection until policy maps it into a preference. Conversely, a well-known mandatory attribute such as AS_PATH can participate directly in best-path logic.

Keep the models separate.

---

9. Scenario — Atlas Attribute Relay

Illustrative lab — not a real incident.

Objective

Use three autonomous systems to observe classic mandatory attributes and demonstrate explicit propagation of a standard community, an optional transitive attribute.

Topology

BGP Path-Attribute Taxonomy: Mandatory, Discretionary, Transitive and Non-Transitive

203.0.113.0/24
     |
 R1 AS65010
192.0.2.1/30
     |
 R2 AS65020
198.51.100.1/30
     |
 R3 AS65030

R1 originates the route. R1 also attaches community 65010:90 using an outbound route map and sends standard communities to R2. R2 is configured to send communities onward to R3.

The lab is intentionally limited: it uses community tagging only to make transitive propagation visible. Full community policy engineering comes later.

---

10. Prerequisites

• Three IOS XE-capable lab nodes.
• Cisco IOS XE 17.18.x documentation baseline.
• Direct eBGP links R1–R2 and R2–R3.
• Console access.
• Optional packet capture.

---

11. Baseline configuration

R1

hostname R1
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
route-map TAG-COMM permit 10
 set community 65010:90 additive
!
router bgp 65010
 bgp router-id 10.10.10.1
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 route-map TAG-COMM out
  neighbor 192.0.2.2 send-community
 exit-address-family

R2

hostname R2
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 ip address 198.51.100.1 255.255.255.252
 no shutdown
!
router bgp 65020
 bgp router-id 10.20.20.2
 neighbor 192.0.2.1 remote-as 65010
 neighbor 198.51.100.2 remote-as 65030
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 send-community
 exit-address-family

R3

hostname R3
interface GigabitEthernet0/0
 ip address 198.51.100.2 255.255.255.252
 no shutdown
!
router bgp 65030
 bgp router-id 10.30.30.3
 neighbor 198.51.100.1 remote-as 65020
 address-family ipv4 unicast
  neighbor 198.51.100.1 activate
 exit-address-family

---

12. Verification before modification

On R2:

show ip bgp 203.0.113.0
show ip bgp neighbors 192.0.2.1 routes
show ip bgp neighbors 198.51.100.2 advertised-routes

On R3:

show ip bgp 203.0.113.0
show ip bgp summary

What to identify

For the target route, record:

• ORIGIN;
• AS_PATH;
• NEXT_HOP;
• community value if displayed;
• whether the route is valid/best according to the local table;
• the difference between attributes received at R2 and those seen at R3.

Do not invent expected formatting. Use the actual command output from the selected image during execution.

---

13. Controlled modification — stop community propagation at R2

On R2:

configure terminal
router bgp 65020
 address-family ipv4 unicast
  no neighbor 198.51.100.2 send-community
 end

Use an appropriate outbound soft refresh/re-advertisement mechanism supported by the lab image if needed to apply the change without an unnecessary hard reset.

Expected result

R3 should continue receiving the prefix and mandatory routing information, while the standard community is no longer sent onward by R2 under the intended Cisco behavior.

This demonstrates an important implementation point: an attribute being transitive in the protocol does not remove the need for vendor-specific configuration that controls whether certain attributes are actually transmitted to a given neighbor.

---

14. Fault injection

Illustrative lab — not a real incident.

Lab name

Atlas Attribute Relay — Lost Policy Tag

Fault

Remove send-community toward R3.

Symptom

Reachability remains present, but a downstream policy tag disappears.

Expected BGP state

All sessions remain Established.

Operational risk

If R3 depends on that community for routing policy, traffic behavior may change even though the prefix and AS_PATH remain visible.

---

15. Troubleshooting workflow

1. Confirm that the prefix is still present at R3.
2. Confirm that R1 still attaches the intended community.
3. Confirm R2 receives the community.
4. Compare R2 inbound route detail with R3 received route detail.
5. Check outbound community transmission configuration on R2.
6. Confirm that no outbound policy intentionally removes the community.
7. Re-advertise/refresh safely if required.
8. Verify the community reappears at R3.
9. Confirm no unintended route preference changed.
10. Preserve before/after route details.

The key principle is that an “attribute problem” is not automatically a “reachability problem.”

---

16. Root cause and correction

Root cause

R2 no longer sends standard communities to R3.

Correction

configure terminal
router bgp 65020
 address-family ipv4 unicast
  neighbor 198.51.100.2 send-community
 end

Why it works

Cisco IOS XE controls community transmission to a neighbor with explicit neighbor configuration. Restoring that behavior allows the standard community attached upstream to be propagated as intended, subject to outbound policy.

---

17. Post-fix verification

On R2:

show ip bgp 203.0.113.0
show ip bgp neighbors 198.51.100.2 advertised-routes

On R3:

show ip bgp 203.0.113.0

Verify both:

• route reachability;
• attribute presence.

A successful ping alone does not prove policy metadata has been restored.

---

18. Rollback

To return to the faulted state, remove send-community; to restore the intended state, re-add it. In production, never use this as a casual test if downstream policy relies on communities.

Preserve route-detail output and policy configuration before changing attribute propagation.

---

19. Production lessons

Standards lesson

Path-attribute taxonomy describes recognition and propagation behavior; it does not define the entire routing-policy meaning of an attribute.

Design lesson

Optional transitive attributes make BGP extensible, but operators still need explicit policy and vendor-aware transmission controls.

Troubleshooting lesson

Inspect the entire route object: NLRI plus the attributes required by the intended policy.

Change-management lesson

A route can remain present while a missing attribute silently changes downstream behavior.

Security lesson

Communities and other policy metadata should be accepted, rewritten or stripped deliberately at trust boundaries rather than blindly propagated.

---

20. Knowledge check

Q1

What are the four RFC 4271 path-attribute categories?

Answer: Well-known mandatory, well-known discretionary, optional transitive and optional non-transitive.

Q2

Is “optional transitive” the same as “always used in best-path selection”?

Answer: No. Transitivity describes propagation behavior, not whether the attribute is a direct best-path criterion.

Q3

Why can a route remain reachable after a community disappears?

Answer: The mandatory reachability/path information can still be present while the optional policy tag is no longer transmitted. The downstream policy effect may change even though the route itself survives.

---

21. Sources

1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — path-attribute categories, flags and base attributes.
2. RFC 1997 — *BGP Communities Attribute* — standard communities as an optional transitive attribute.
3. RFC 7606 — *Revised Error Handling for BGP UPDATE Messages* — robust handling of malformed path attributes.
4. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x* — BGP neighbor/address-family policy behavior.
5. Cisco — *Cisco IOS IP Routing: BGP Command Reference* — route and neighbor inspection commands.

Accessed: 2026-08-11.

---