Border Gateway Protocol (BGP)

BGP routes carry far more than just destination prefixes and AS paths. Each route is annotated with a collection of path attributes—metadata that describes the route's characteristics, origin, policies, and preferences. These attributes collectively enable the sophisticated policy-based routing that makes BGP suitable for the Internet.

Understanding BGP attributes is essential for any network engineer working with BGP. Attributes determine which routes are selected, how they propagate, and how traffic flows across the Internet. Mastering attribute manipulation is the key to effective BGP traffic engineering.

BGP path attributes are classified along two dimensions, creating four categories that determine how attributes are processed and propagated.

Classification Dimensions:

1. Well-Known vs. Optional

• Well-Known: Must be recognized by all BGP implementations
• Optional: May not be recognized by all implementations

2. Mandatory vs. Discretionary (for Well-Known) / Transitive vs. Non-Transitive (for Optional)

• Mandatory: Must be present in every UPDATE message
• Discretionary: May or may not be present
• Transitive: Propagated even if not recognized
• Non-Transitive: Discarded if not recognized

Attribute Encoding:

Each attribute in an UPDATE message has a standard format:

+---------------------------+
| Attr. Flags (1 byte)      |
+---------------------------+
| Attr. Type Code (1 byte)  |
+---------------------------+
| Attr. Length (1-2 bytes)  |
+---------------------------+
| Attr. Value (variable)    |
+---------------------------+

Attribute Flags (bit fields):

• Bit 0: Optional (1) vs. Well-Known (0)
• Bit 1: Transitive (1) vs. Non-Transitive (0)
• Bit 2: Partial (1) = recognized transitive but not fully processed
• Bit 3: Extended Length (1) = 2-byte length field

The ORIGIN attribute indicates how the route was originally introduced into BGP. It's a well-known mandatory attribute that influences path selection.

ORIGIN Values:

ORIGIN in Best Path Selection:

ORIGIN is step 5 in the BGP decision process, after AS_PATH length. Lower origin values are preferred:

IGP (0) > EGP (1) > INCOMPLETE (2)

This preference reflects trustworthiness: routes learned from an IGP are considered more reliable than routes injected through redistribution.

Practical Example:

NEXT_HOP is a well-known mandatory attribute that specifies the IP address of the next-hop router to reach the advertised destinations. This attribute's behavior differs significantly between eBGP and iBGP.

NEXT_HOP Behavior:

The iBGP NEXT_HOP Challenge:

When R1 receives a prefix from AS 65002 with NEXT_HOP 192.0.2.1, it advertises via iBGP to R2 and R3 without changing the NEXT_HOP. This means R2 and R3 must be able to reach 192.0.2.1.

Solutions:

1. IGP Routing: The IGP (OSPF/IS-IS) carries the route to 192.0.2.1

   • Common and scalable
   • Requires redistributing external network or enabling next-hop as passive

2. next-hop-self: R1 sets itself as next-hop when advertising to iBGP peers

   • Simple and commonly used
   • Hides external topology from internal routers

3. Recursive lookup: R2/R3 recursively resolve 192.0.2.1 through IGP

   • Default behavior; requires IGP reachability

LOCAL_PREF is a well-known discretionary attribute used within an AS to indicate the degree of preference for a route. It is the most powerful policy tool in BGP because it appears early in the decision process (step 2, after weight).

Key Characteristics:

LOCAL_PREF Scope:

Crucially, LOCAL_PREF is never sent to eBGP peers. It's an internal policy knob that tells your own AS which path to prefer. When advertising to external peers, LOCAL_PREF is stripped from the UPDATE.

Policy Application:

LOCAL_PREF is typically set on inbound route-maps to implement policy:

ISP Traffic Engineering with LOCAL_PREF:

ISPs use LOCAL_PREF to implement the customer > peer > provider preference hierarchy:

MED (also called METRIC in some implementations) is an optional non-transitive attribute used to influence inbound traffic across multiple entry points into an AS.

Key Characteristics:

MED Purpose:

MED allows an AS to tell its neighbor which entry point to prefer for reaching a specific prefix. It's the only standard mechanism for influencing an external AS's inbound path selection.

Non-Transitive Implication:

Because MED is non-transitive, it only influences the directly connected AS. That AS will not propagate the MED to its peers—they'll apply their own policies.

In this example, AS 65001 advertises the same prefix via two peering points with different MEDs. AS 65002 will prefer the path through the East Router (MED 100 < MED 200), sending traffic to the closer ingress point.

MED Comparison Rules:

By default, MED is only compared between routes received from the same neighboring AS. This prevents unfair comparisons—MEDs from different ASes may use different scales.

The COMMUNITY attribute is one of BGP's most powerful and flexible features. It allows routes to be tagged with arbitrary labels that can trigger policy actions across multiple ASes.

Key Characteristics:

Community Format:

Communities are 32-bit values, typically displayed in two formats:

• Decimal: 4294967041
• ASN:NN notation: 65000:1 (high 16 bits = ASN, low 16 bits = community ID)

Well-Known Communities (RFC 1997):

Operator-Defined Communities:

Beyond well-known communities, operators define their own to signal intent. Common patterns include:

Extended Communities and Large Communities:

Standard 32-bit communities have limitations (16-bit ASN field). Extensions address this:

Large Communities are essential for operators with 4-byte AS numbers (above 65535), as they provide proper 32-bit ASN fields in the community value.

Now that we've examined individual attributes, let's see how they combine in the BGP best path selection algorithm. This process runs whenever a router has multiple paths to the same prefix.

The Full Decision Algorithm:

BGP applies these criteria in order. As soon as one criterion produces a clear winner, the process stops.

Decision Process Example:

Router receives three paths to 10.0.0.0/8:

Decision Steps:

1. All routes valid ✓
2. Weight: All default (0), continue
3. LOCAL_PREF: A=150, B=100, C=150 → Eliminate B, continue with A and C
4. Not locally originated, continue
5. AS_PATH length: A=2, C=3 → A wins (shorter path)

Path A is selected. Note that even though C had the same LOCAL_PREF, AS_PATH length broke the tie.

BGP attributes form the vocabulary through which routing policy is expressed. Let's consolidate the key concepts:

What's Next:

In the final page of this module, we explore the critical distinction between eBGP and iBGP. You will learn why BGP uses different behaviors for internal and external sessions, how route reflectors and confederations solve iBGP scaling challenges, and the operational differences in configuring and troubleshooting each session type.