Path Vector Routing

In an ideal world, packets would always take the shortest path to their destination. But the internet isn't just a technical system—it's an economic and political ecosystem where routing decisions must reflect business relationships, contractual obligations, regulatory requirements, and security policies.

A large enterprise might prefer routing traffic through a more expensive but faster provider for latency-sensitive applications. A European bank might be legally required to avoid routing customer data through certain jurisdictions. A content provider might want to utilize paid peering agreements before falling back to transit providers.

Policy routing enables these decisions. Path vector routing's visibility into the complete AS path empowers operators to implement sophisticated policies that align network behavior with organizational objectives—something impossible with simple hop-count or cost-based routing.

Policy routing is the practice of making routing decisions based on criteria other than—or in addition to—the destination address and shortest path. In the context of BGP and path vector protocols, policy routing means controlling which routes are accepted, preferred, and advertised based on organizational requirements.

Why Policy Routing Exists:

The internet is not a homogeneous network with a single objective (like minimizing latency). It's a collection of autonomous systems with diverse and sometimes conflicting goals:

The Policy Dimension:

Traditional IGP routing asks: "What's the shortest path to this destination?"

Policy routing asks: "What's the best path considering:

• Business relationships (customer, peer, provider)?
• Cost implications?
• Performance requirements?
• Legal and regulatory constraints?
• Security concerns?
• Contractual obligations?"

The "best" path may not be the shortest. An organization might deliberately choose a longer path that costs less, performs better, or complies with regulations.

Path Vector Enables Policy:

Path vector routing is uniquely suited to policy implementation because it provides:

1. Path Visibility: See exactly which ASNs traffic will traverse
2. Multiple Attributes: Rich set of attributes for expressing preferences
3. Per-Prefix Control: Different policies for different destinations
4. Inbound and Outbound Control: Influence both directions of traffic
5. Community Signaling: Communicate policies to other networks

BGP provides multiple points where policy can be applied. Understanding these control points is essential for implementing effective routing policies.

Import Policy (Inbound):

Applied to routes received from neighbors before they enter the routing table:

Neighbor → [Import Filter] → Adj-RIB-In → [Best Path Selection] → Loc-RIB

Import policies can:

• Reject routes entirely (filtered out)
• Modify attributes (change local preference, add communities)
• Accept routes unchanged

Export Policy (Outbound):

Applied to routes advertised to neighbors after selection:

Loc-RIB → [Export Filter] → Adj-RIB-Out → Neighbor

Export policies can:

• Prevent routes from being advertised
• Modify attributes before advertisement (prepend AS path, set MED)
• Accept routes unchanged

Controlling Traffic Direction:

A critical concept is understanding that BGP policy controls route advertisements, not packets directly. This creates an asymmetric relationship:

Why the asymmetry?

• Outbound: You control which routes you install, so you control where your traffic exits
• Inbound: You can only suggest entry points; other networks make their own decisions

This is why inbound traffic engineering is more complex—you're trying to influence others' routing decisions through advertisements, not direct control.

Attribute Modification Scope:

BGP's path selection algorithm evaluates attributes in a strict order. Understanding this hierarchy is crucial for implementing policies that behave as expected.

The Decision Hierarchy:

When comparing paths to the same prefix, BGP evaluates in order (simplified):

Policy Implementation Strategy:

Knowing the hierarchy guides which attributes to manipulate:

Example: Preferring Customer Routes:

A transit provider wants traffic to exit toward customers (paying them) rather than peers (free) or upstream transit (costs them):

Import from customer:   set local-preference 150
Import from peer:       set local-preference 100  (default)
Import from transit:    set local-preference 80

Result: Customer routes always preferred (150 > 100 > 80), regardless of AS path length.

Real-world BGP policies follow well-established patterns. Understanding these patterns accelerates policy design and helps avoid common mistakes.

Pattern 1: Customer/Peer/Transit Preference

The most fundamental policy for any multi-homed network:

Business Relationship → Local Preference
Customer (pays you)   → 150 (highest)
Peer (free exchange)  → 100 (default)
Transit (you pay)     → 80  (lowest)

This ensures traffic exits toward paying customers first, maximizing revenue while minimizing transit costs.

Pattern 2: Primary/Backup Links

Using local preference to designate primary and backup connections:

Primary link:  local-preference 120
Backup link:   local-preference 80

Failover: When primary fails, backup takes over automatically

More sophisticated implementations use BFD for sub-second failover detection.

Pattern 3: AS Path Filtering

Reject routes based on AS path content—essential for security and policy compliance:

Deny if AS path contains:
  - Your own AS (loop prevention, standard)
  - Sanctioned countries' AS ranges
  - Known bogon/hijacked ASNs
  - Specific competitor ASNs (rare, controversial)

Pattern 4: Prefix Filtering

Control route acceptance based on prefix characteristics:

Deny:
  - RFC 1918 private addresses (10.0.0.0/8, etc.)
  - Bogon prefixes (not allocated by RIRs)
  - Prefixes > /24 (too specific for global table)
  - Default route (0.0.0.0/0) unless explicitly expected
  
Allow:
  - Prefixes documented in customer agreements
  - Prefixes in IRR/RPKI with valid authorization

Pattern 5: Selective Advertisement

Control which routes are advertised to which neighbors:

To Customers:   Advertise all routes (customer pays for transit)
To Peers:       Advertise own + customer routes (no transit to peers)
To Transit:     Advertise own + customer routes (don't pay for others)

This prevents paying transit costs for traffic that should flow through peers, and prevents peers from using you as free transit.

BGP communities are the Swiss Army knife of policy routing. These 32-bit tags (or 96-bit for large communities) travel with routes across AS boundaries, enabling sophisticated policy signaling between organizations.

Community Structure:

Standard Community: 16-bit ASN : 16-bit value
Example: 65001:100   means "AS 65001, tag 100"

Large Community: 32-bit ASN : 32-bit value : 32-bit value
Example: 136907:100:200   (for 4-byte ASNs)

Well-Known Communities:

RFC defines special communities with universal meaning:

These are honored by most BGP implementations without configuration.

Operator-Defined Communities:

Most communities are defined by individual operators. Common patterns:

Informational (marking):
  ASN:100 - Route learned from customer
  ASN:200 - Route learned from peer
  ASN:300 - Route learned from transit
  ASN:1XX - Route learned in region XX

Actionable (requesting action):
  ASN:0 - Blackhole this prefix (DDoS mitigation)
  ASN:666 - Blackhole (alternative convention)
  ASN:1000 - Prepend 1x to all peers
  ASN:2000 - Prepend 2x to all peers
  ASN:10XX - Prepend to specific AS (10 + AS suffix)

Controlling inbound traffic—packets destined to your network—is one of the most challenging aspects of BGP operations. Unlike outbound traffic where you control route selection, inbound traffic is determined by other networks' routing decisions.

The Fundamental Challenge:

You can influence, but not directly control, how others route to you:

                     ┌─────────────┐
                     │   Your      │
                     │   Network   │
                     │   (AS 65001)│
        ┌────────────┴──────┬──────┴────────────┐
        │                   │                   │
   ┌────▼────┐         ┌────▼────┐         ┌────▼────┐
   │ Transit │         │  Peer   │         │  Peer   │
   │   ISP   │         │    A    │         │    B    │
   └────┬────┘         └────┬────┘         └────┬────┘
        │                   │                   │
        └───────────────────▼───────────────────┘
                        Internet
                        
    "Where does inbound traffic enter?"

You want traffic to enter via the peers (free) rather than transit (costs money). How do you convince the rest of the internet?

Technique 1: AS Path Prepending

Make certain paths appear longer (less attractive):

Current advertisement:
  Via Transit: 192.0.2.0/24, AS_PATH: 65010 65001
  Via Peer-A:  192.0.2.0/24, AS_PATH: 65020 65001

After prepending via Transit:
  Via Transit: 192.0.2.0/24, AS_PATH: 65010 65001 65001 65001
  Via Peer-A:  192.0.2.0/24, AS_PATH: 65020 65001

Result: AS path via Transit is now 4 vs 2 for Peer-A
        Remote networks will prefer Peer-A

Prepending Considerations:

• Each prepend increases path length by 1
• Typically 1-3 prepends are sufficient
• More than 4-5 prepends provides diminishing returns
• Excessive prepending looks unprofessional and may be filtered

Technique 2: Selective Advertisement

Advertise specific prefixes only via preferred links:

Your prefix: 192.0.2.0/24 (customer allocation)

Option A: Advertise only via peers
  → Traffic MUST come via peers
  → Transit won't know about your prefix
  → Risk: Reduced reachability if peers fail

Option B: More specific via peers, aggregate via transit
  Peers:   192.0.2.0/25 + 192.0.2.128/25
  Transit: 192.0.2.0/24
  
  → More-specific prefixes preferred
  → Fallback to transit if peers fail

Technique 3: MED (Multi-Exit Discriminator)

Suggest your preferred entry point to neighbors:

Advertise to peer with multiple connections:
  Chicago link: MED 100 (prefer this)
  Denver link:  MED 200 (less preferred)

Neighbor may honor this if they:
  - Compare MED at all (some don't)
  - Haven't set higher-priority attributes

MED is a hint, not a directive. Many networks ignore or filter MED.

Policy routing's flexibility comes with security responsibilities. Misconfigured policies can expose networks to hijacking, leak routes inappropriately, or cause widespread reachability problems.

Route Hijacking:

Malicious or misconfigured networks can advertise prefixes they don't own:

Legitimate owner (AS 65030): 192.0.2.0/24 with AS_PATH 65030
Hijacker (AS 65999):         192.0.2.0/24 with AS_PATH 65999

If hijacker's path looks shorter or more attractive to your
upstreams, traffic to 192.0.2.0/24 goes to the hijacker.

Defense: Prefix Filtering

Always filter what you accept from customers and peers:

For each customer:
  - Document their assigned prefixes
  - Filter import to ONLY those prefixes
  - Verify via IRR/RPKI before accepting

For peers:
  - Use IRR data (RADB, RIPE, etc.) for prefix lists
  - Implement RPKI ROA validation
  - Reject bogon prefixes unconditionally

Route Leaks:

Route leaks occur when routes are advertised to neighbors that shouldn't receive them:

Example: Customer learns full table from you (transit)
         Customer accidentally advertises full table to peer
         Peer thinks customer is transit for entire internet
         Traffic blackholes or takes suboptimal paths

Famous incidents (YouTube 2008, Google 2017, Cloudflare 2019) caused widespread outages due to route leaks.

Defense: Export Filtering

To peers: ONLY advertise your prefixes + customer prefixes
To customers: Advertise full table or customer-specific
To transit: ONLY advertise your prefixes + customer prefixes

NEVER: Advertise routes learned from peers to other peers
NEVER: Advertise routes from transit to peers
NEVER: Accept more-specific prefixes for your own space

Policy routing transforms BGP from a simple path-exchange protocol into a sophisticated business logic engine. Understanding how to leverage BGP attributes, communities, and filtering enables you to align network behavior with organizational objectives while maintaining security.

Key Concepts Mastered:

What's Next:

With policy routing foundations established, we turn to the protocol that embodies path vector routing: BGP (Border Gateway Protocol). The next page explores BGP's architecture, operation, and how it implements the path vector concepts we've covered.