Once BGP sessions are established, the real work begins: exchanging routing information. Every prefix reachable on the Internet—from major cloud provider address blocks to small business networks—is advertised through BGP UPDATE messages that propagate across autonomous system boundaries.

Route advertisement in BGP is far more sophisticated than simple prefix announcements. Each route carries rich metadata in the form of path attributes that describe how the route was learned, what path it takes through the network, and how it should be treated. Understanding route advertisement mechanics is essential for anyone operating, designing, or troubleshooting inter-domain routing.

The BGP UPDATE message is the workhorse of inter-domain routing, carrying all routing information between BGP peers. Its structure is carefully designed to efficiently communicate route announcements and withdrawals.

UPDATE Message Format:

+----------------------------------------------+
| Withdrawn Routes Length (2 bytes)            |
+----------------------------------------------+
| Withdrawn Routes (variable)                  |
|   - Prefix length (1 byte)                   |
|   - Prefix (variable, rounded up to bytes)   |
+----------------------------------------------+
| Total Path Attribute Length (2 bytes)        |
+----------------------------------------------+
| Path Attributes (variable)                   |
|   - Attribute Type (2 bytes)                 |
|     - Flags (1 byte)                         |
|     - Type Code (1 byte)                     |
|   - Attribute Length (1 or 2 bytes)          |
|   - Attribute Value (variable)               |
+----------------------------------------------+
| Network Layer Reachability Information       |
| (NLRI - variable)                            |
|   - Prefix length (1 byte)                   |
|   - Prefix (variable, rounded up to bytes)   |
+----------------------------------------------+

Key Structural Observations:

1. Withdrawals First: Withdrawn routes are listed before new announcements, allowing receivers to process removals before additions

2. Shared Attributes: All prefixes in the NLRI section share the same path attributes—this enables batching of announcements with identical characteristics

3. Variable Length Encoding: Both prefixes and attribute values use variable-length encoding to minimize message size

4. Empty UPDATE Messages: An UPDATE with no withdrawn routes and no NLRI (just attributes, or completely empty) is valid and serves as a keepalive

NLRI Encoding Example:

Consider announcing the prefix 192.0.2.0/24:

Prefix Length: 24 (1 byte: 0x18)
Prefix: 192.0.2 (3 bytes: 0xC0 0x00 0x02)

Note that only the network portion is included—the host portion (trailing zeros) is omitted. A /24 requires 3 bytes, a /16 requires 2 bytes, and a /8 requires 1 byte.

For IPv6 with Multiprotocol BGP, NLRI is carried inside the MP_REACH_NLRI attribute rather than the main NLRI field.

Path attributes are the metadata that BGP attaches to routes. They describe the route's origin, its path through the network, and how it should be handled. Attributes are classified by two independent criteria.

Attribute Flags (First Byte of Attribute Type):

Attribute Classification Matrix:

Handling Rules:

1. Well-known Mandatory: Must be present in every UPDATE with NLRI. If missing, the UPDATE is malformed.

2. Well-known Discretionary: Must be recognized by all implementations but may be absent.

3. Optional Transitive: If not recognized, passed to neighbors with the Partial bit set.

4. Optional Non-Transitive: If not recognized, silently discarded.

Every BGP UPDATE message with NLRI must include the three well-known mandatory attributes: ORIGIN, AS_PATH, and NEXT_HOP. Understanding these attributes is fundamental to BGP operation.

ORIGIN Attribute (Type 1)

The ORIGIN attribute indicates how the route was originally introduced into BGP:

ORIGIN is used in route selection: IGP is preferred over EGP, which is preferred over INCOMPLETE.

AS_PATH Attribute (Type 2)

The AS_PATH is perhaps the most important BGP attribute. It records the sequence of ASes that a route has traversed, serving two critical functions:

1. Loop Prevention: A BGP speaker rejects routes containing its own AS number in the AS_PATH
2. Path Selection: Shorter AS_PATHs are generally preferred

AS_PATH consists of path segments, each with a type and list of AS numbers:

Example AS_PATH:

AS_PATH: 65002 65005 65010

This indicates the route was received from AS 65002, which received it from AS 65005, which received it from AS 65010 (the origin).

NEXT_HOP Attribute (Type 3)

The NEXT_HOP attribute specifies the IP address that should be used to reach the advertised prefixes. Its handling differs significantly between eBGP and iBGP:

eBGP NEXT_HOP Behavior:

• When advertising to an eBGP peer, NEXT_HOP is set to the advertising router's own address (the interface used for the session)
• When receiving from an eBGP peer, accept the received NEXT_HOP

iBGP NEXT_HOP Behavior:

• NEXT_HOP is NOT changed when advertising to iBGP peers
• The NEXT_HOP learned from eBGP is preserved and propagated within the AS
• This means iBGP routers must be able to reach the eBGP NEXT_HOP (via IGP)

The NEXT_HOP Reachability Problem:

Consider this topology:

[AS 65001]                        [AS 65002]
             10.0.0.1    10.0.0.2
    R1 --------- R2 ===== R3
                  |       
                  | iBGP
                  |
                 R4

1. R3 advertises prefix 192.0.2.0/24 to R2 via eBGP with NEXT_HOP = 10.0.0.2
2. R2 receives the route and installs it with NEXT_HOP = 10.0.0.2
3. R2 advertises to R4 via iBGP, preserving NEXT_HOP = 10.0.0.2
4. R4 receives the route but cannot reach 10.0.0.2 (it's not in AS 65001's IGP)

Solutions:

1. Add 10.0.0.0/24 to AS 65001's IGP (redistribute connected on R2)
2. Use neighbor x.x.x.x next-hop-self to force R2 to change NEXT_HOP to its own address
3. Peer using loopback addresses that are in the IGP

While mandatory attributes are essential for basic routing, optional attributes provide the control and flexibility needed for sophisticated routing policies.

LOCAL_PREF Attribute (Type 5)

LOCAL_PREF is used exclusively within an AS to influence outbound traffic. It's a 32-bit value; higher values are preferred.

Key characteristics:

• Well-known discretionary (all BGP speakers must recognize it)
• Only exchanged between iBGP peers (never sent to eBGP)
• Default value: 100 (configurable)
• Used to prefer certain external routes over others

Example Use Case:

AS 65001 has two connections to AS 65002:
- Primary via R1: Set LOCAL_PREF = 200
- Backup via R2: Set LOCAL_PREF = 50

All routers in AS 65001 will prefer routes learned via R1.

MED Attribute (Type 4 - Multi-Exit Discriminator)

MED is used to communicate preferences to external neighbors for inbound traffic. It's a 32-bit value; lower values are preferred.

Key characteristics:

• Optional non-transitive (not propagated beyond directly connected AS)
• Used to prefer one entry point over another when receiving routes from the same AS
• Only comparable between routes from the same neighboring AS
• Default: Absent (implementation-specific handling if missing)

Example Use Case:

AS 65002 advertises 192.0.2.0/24 via two links to AS 65001:
- Via R2: MED = 100
- Via R3: MED = 200

AS 65001 (if honoring MED) will prefer the path via R2.

COMMUNITY Attribute (Type 8)

Communities are 32-bit tags that enable flexible policy expression. Routes can carry multiple communities, and policies can match, add, or remove them.

Standard format: AS:value (e.g., 65001:100)

Well-Known Communities (RFC 1997):

Community Use Cases:

1. Customer Classification: 65001:1000 = customer, 65001:2000 = peer
2. Routing Policy: 65001:666 = blackhole this prefix
3. Traffic Engineering: 65001:3001 = prepend 1x to AS 65003
4. Geographic Tag: 65001:840 = learned in US

Extended Communities (Type 16):

Extended communities provide 8 bytes (versus 4 for standard) and support typed values:

• Route Targets: VPN membership (e.g., RT 65001:1)
• Site of Origin: Traffic identification (e.g., SoO 65001:100)
• Color: SR-TE policy association

Large Communities (Type 32):

Large communities (RFC 8092) provide 12 bytes, designed for 4-byte AS numbers:

• Format: Global Admin (4 bytes) : Local Data 1 (4 bytes) : Local Data 2 (4 bytes)
• Example: 4200000001:1:100

Understanding how routes are announced and propagated is essential for predicting BGP behavior and troubleshooting routing issues.

Route Origination:

Routes enter BGP through several mechanisms:

1. Network Statement: Explicitly configure prefixes to advertise

router bgp 65001
  network 192.0.2.0 mask 255.255.255.0

Requires a matching route in the routing table (exact match typically required).

2. Redistribution: Import routes from other protocols

router bgp 65001
  redistribute ospf 1 route-map OSPF-TO-BGP

Use with caution—can create routing loops or table bloat.

3. Aggregation: Summarize multiple specific routes

router bgp 65001
  aggregate-address 192.0.0.0 255.255.0.0 summary-only

Outbound Route Processing:

When advertising routes to a peer, BGP applies a sequence of operations:

1. Check route validity: Route must be in BGP table and have reachable NEXT_HOP
2. Apply outbound policy: Filter routes, modify attributes
3. Check AS loop: Don't advertise routes where peer's AS is in AS_PATH
4. Split horizon: For iBGP, don't re-advertise iBGP-learned routes to other iBGP peers
5. NEXT_HOP modification: For eBGP, change NEXT_HOP to self
6. AS_PATH prepending: For eBGP, prepend local AS

Incremental Updates:

BGP uses incremental updates rather than periodic full table exchanges. After the initial table exchange when a session is established:

• New routes are announced in UPDATE messages
• Changed routes (new best path) are announced with new attributes
• Removed routes are explicitly withdrawn

This incremental approach dramatically reduces bandwidth and processing overhead compared to link-state protocols that exchange complete databases.

Minimum Route Advertisement Interval (MRAI):

To prevent update storms, BGP limits how frequently routes can be advertised:

• eBGP: Default 30 seconds between advertisements for the same prefix
• iBGP: Default 0 seconds (immediate)

This means if a route changes multiple times within 30 seconds, only the final state is advertised, reducing update volume but increasing convergence time.

When a route is no longer valid, BGP must inform its peers to stop using it. Route withdrawal is a critical operation that directly impacts traffic forwarding.

Withdrawal Triggers:

1. Administrative Action: Route removed from configuration
2. IGP Withdrawal: Underlying IGP route disappears (if using redistribution)
3. NEXT_HOP Unreachable: IGP path to NEXT_HOP fails
4. Session Loss: Peer goes down (all routes from that peer withdrawn)
5. Policy Change: Route now filtered by updated policy

Withdrawal Message Format:

Withdrawals are carried in the UPDATE message's Withdrawn Routes field:

+---------------------------+
| Withdrawn Routes Length   |  (e.g., 7 bytes)
+---------------------------+
| Withdrawn Routes          |
|   Length: 24, Prefix: 192.0.2.0  (4 bytes)
|   Length: 16, Prefix: 10.0.0    (3 bytes)
+---------------------------+

Note: No path attributes are needed for withdrawals—just the prefix identification.

Withdrawal Propagation:

When a BGP router receives a withdrawal:

1. Remove the route from the Adj-RIB-In (routes received from this peer)
2. If this was the best path, run best path selection on remaining paths
3. If a new best path exists, advertise it to neighbors
4. If no paths remain, propagate the withdrawal to neighbors

Convergence Time Considerations:

Withdrawals typically converge faster than announcements because:

1. No MRAI for Withdrawals: Most implementations send withdrawals immediately
2. Implicit Validity: Receiving routers immediately mark routes invalid
3. Parallel Processing: Multiple routers process withdrawals simultaneously

However, path exploration (when multiple paths exist) can cause temporary routing instability:

1. Router receives withdrawal for best path
2. Selects new (potentially suboptimal) path
3. Receives update for that path (also withdrawn)
4. Explores next path
5. Continues until stable

This path exploration can generate many UPDATE messages as the network reconverges.

Route aggregation (summarization) is essential for Internet scalability. Without aggregation, the global routing table would be unmanageable—every small network would require a separate entry in every router's memory.

Why Aggregate?

1. Reduce Table Size: Fewer entries = less memory, faster lookups
2. Reduce Update Volume: Changes to specific routes don't propagate past the aggregate
3. Improve Stability: Aggregates mask flapping of more-specific routes
4. Allocator Efficiency: Hierarchical allocation enables aggregation

BGP Aggregation Commands:

router bgp 65001
  ! Basic aggregation - both aggregate and specifics advertised
  aggregate-address 192.0.0.0 255.255.0.0
  
  ! Summary-only - suppress specific routes
  aggregate-address 192.0.0.0 255.255.0.0 summary-only
  
  ! AS-SET - include contributing ASes in AS_PATH
  aggregate-address 192.0.0.0 255.255.0.0 as-set

Aggregation Mechanics:

When BGP creates an aggregate:

1. There must be at least one more-specific route in the BGP table
2. A new route for the aggregate prefix is created
3. ORIGIN is set to IGP (or INCOMPLETE if different origins exist)
4. AS_PATH depends on configuration:
   • Without AS-SET: Local AS only
   • With AS-SET: AS_SET segment containing all contributing ASes
5. ATOMIC_AGGREGATE attribute may be set
6. AGGREGATOR attribute may be added

The Aggregation Information Loss Problem:

Aggregation inherently loses information. When you aggregate 192.0.2.0/24 (AS 65001), 192.0.3.0/24 (AS 65002), and 192.0.4.0/24 (AS 65003) into 192.0.0.0/22:

• Without AS-SET: The aggregate's AS_PATH shows only your AS. Routers can't detect loops if 65001, 65002, or 65003 receive the aggregate.

• With AS-SET: The aggregate's AS_PATH includes {65001, 65002, 65003} as an unordered set. Loop detection works, but AS_PATH length calculation uses the set as length 1.

ATOMIC_AGGREGATE Attribute:

This well-known discretionary attribute indicates that:

1. The advertising router performed aggregation
2. Information may have been lost (AS_PATH shortened)
3. Receivers should not de-aggregate (which would be incorrect anyway)

AGGREGATOR Attribute:

This optional transitive attribute records:

• AS number of the router that created the aggregate
• BGP Identifier (Router ID) of that router

Useful for troubleshooting—you can trace who created a suspicious aggregate.

Route filtering is the primary mechanism for implementing BGP policy. By controlling which routes are accepted and advertised, network operators shape traffic flow, enforce business relationships, and protect network security.

Filtering Directions:

Filtering Mechanisms:

1. Prefix Lists: Filter based on prefix and length

ip prefix-list CUSTOMER-IN seq 10 permit 192.0.2.0/24
ip prefix-list CUSTOMER-IN seq 20 permit 198.51.100.0/22 le 24

2. AS-Path Filters: Filter based on AS_PATH content

ip as-path access-list 1 permit ^65001$       ! Origin AS 65001
ip as-path access-list 2 deny _65002_          ! Transit via AS 65002

3. Community Filters: Filter based on community values

ip community-list standard BLACKHOLE permit 65001:666
ip community-list expanded CUSTOMER permit ^65001:1[0-9]{3}$

4. Route Maps: Combine multiple criteria with attribute modifications

route-map CUSTOMER-IN permit 10
  match ip address prefix-list CUSTOMER-PREFIXES
  match as-path 1
  set local-preference 150
  set community 65001:1000 additive

Policy Application Order:

BGP applies policies at specific points in route processing:

1. Receive UPDATE from peer
2. Apply inbound policy (prefix filter, route-map)
3. Store in Adj-RIB-In (if not filtered)
4. Run best path selection (choose best route per prefix)
5. Store best path in Loc-RIB (local routing table)
6. For each peer, apply outbound policy
7. Store permitted routes in Adj-RIB-Out (per-peer)
8. Send UPDATE to peer

This model means inbound filtering reduces memory usage (routes never stored) while outbound filtering only affects what's advertised.

Route advertisement is the mechanism by which BGP propagates routing information across the Internet. Mastering UPDATE messages, path attributes, and advertisement behavior is essential for operating production BGP networks.

What's Next:

Now that you understand how routes are advertised, the next page explores route selection—the algorithm BGP uses to choose the best path when multiple paths exist to the same destination. You'll learn the complete best path selection algorithm and how various attributes influence the decision.