At the edge of every Autonomous System, a profound transition occurs. Inside, routers speak the language of IGPs—exchanging topology information, calculating shortest paths, optimizing for performance metrics. Outside, the conversation shifts to BGP—policy-driven, path-aware, navigating the complex politics of inter-organizational connectivity.

The AS boundary is where these worlds meet. It's where your network's internal efficiency connects to the global Internet's scalability. It's where technical metrics give way to business policies. It's where the decisions you make propagate outward to affect routing across the entire Internet.

Understanding AS boundaries is essential for anyone designing, operating, or securing Internet-connected infrastructure. These demarcation points are simultaneously the most critical and most vulnerable parts of any network architecture.

An AS boundary is not a single device but an architectural zone where multiple functions converge. Let's dissect its components:

Key Roles at AS Boundaries:

The ASBR in Detail:

The Autonomous System Boundary Router (ASBR) is the critical device at every AS edge. It performs multiple simultaneous roles:

1. BGP Speaker: Maintains eBGP sessions with external peers and iBGP sessions with internal routers

2. Protocol Bridge: Translates between IGP's metric-based world and BGP's attribute-based world

3. Policy Enforcement Point: Applies import/export policies that implement business decisions

4. Security Perimeter: First line of defense against external routing attacks

5. Traffic Entry/Exit Point: Handles all traffic entering and leaving the AS

A typical ASBR runs:

• eBGP to one or more external peers
• iBGP to internal routers or route reflectors
• An IGP (OSPF, IS-IS, EIGRP) for internal reachability
• Often MPLS for traffic engineering or VPN services

IGP and BGP serve complementary purposes but must work together at AS boundaries. Understanding their interaction is crucial for correct operation.

The Division of Labor:

Critical Interaction: NEXT_HOP Resolution

One of the most important IGP-BGP interactions is next-hop resolution. When BGP learns a route, the NEXT_HOP attribute tells where to forward traffic. But this next-hop IP must be reachable:

1. For eBGP: The next-hop is typically the eBGP peer's IP address, which is usually directly connected (or via a static route for multi-hop eBGP)

2. For iBGP: By default, iBGP doesn't change the NEXT_HOP. If Router A learns a route via eBGP with NEXT_HOP 203.0.113.1, it advertises that same next-hop to iBGP peers. Those peers must have IGP reachability to 203.0.113.1.

Common Solutions for iBGP Next-Hop:

• Include edge networks in IGP: Advertise the eBGP peering subnets via OSPF/IS-IS
• Use next-hop-self: ASBR changes NEXT_HOP to its own address when advertising to iBGP
• Redistribute connected: Include directly connected networks in IGP redistribution

If NEXT_HOP is unreachable, the BGP route is invalid and not installed in the routing table—a common troubleshooting scenario.

Synchronization Rule (Historical Note):

Older BGP implementations enforced "synchronization"—BGP wouldn't advertise a route unless it was also in the IGP. This prevented black-holing when internal routers didn't know how to reach the BGP next-hop. Modern networks disable synchronization (no synchronization) and rely on proper iBGP design (full mesh or route reflectors) instead.

At AS boundaries, routes must often flow between protocols—IGP routes advertised via BGP, BGP routes injected into IGP for internal consumption. This redistribution is powerful but requires careful design.

Common Redistribution Scenarios:

IGP to BGP Redistribution:

When advertising your internal networks to the Internet, you typically don't redistribute all IGP routes. Instead, you:

1. Use BGP network statements: Explicitly specify prefixes to advertise
2. Aggregate at the boundary: Advertise summary routes (e.g., /22 instead of four /24s)
3. Filter with route-maps: If redistributing, control exactly what's included

BGP to IGP Redistribution (Caution!):

Redistributing BGP routes into IGP is generally avoided because:

1. Scale: The full Internet table (900,000+ prefixes) would overwhelm most IGPs
2. Stability: BGP churn would cause constant IGP reconvergence
3. iBGP exists: Internal distribution of external routes is iBGP's job

However, limited redistribution may be appropriate:

• Small stub networks without iBGP capability
• Injecting a default route into IGP
• Specific external prefixes needed in IGP (partner networks, cloud connections)

Filtering at AS boundaries is essential for security, policy enforcement, and protecting the global routing system. Both inbound (routes you accept) and outbound (routes you advertise) filtering are critical.

Inbound Filtering (What You Accept):

Outbound Filtering (What You Advertise):

AS boundaries are high-value targets for attackers. Compromising or manipulating routing at these points can enable traffic interception, denial of service, or credential theft. Security must be layered and comprehensive.

BGP Session Security:

RPKI (Resource Public Key Infrastructure):

RPKI provides cryptographic verification of who is authorized to originate a prefix:

1. Route Origin Authorizations (ROAs): Signed attestations that AS X can originate prefix Y
2. RPKI Validators: Software that fetches and validates ROAs from trust anchors (RIRs)
3. Route Origin Validation (ROV): Routers query validators to classify routes as:
   • Valid: ROA exists and matches
   • Invalid: ROA exists but doesn't match (likely hijack)
   • Not Found: No ROA exists (can't be validated)

RPKI Deployment:

AS boundaries are where technical routing meets business reality. The configurations you apply encode business decisions about which paths traffic should take, who pays whom, and how relationships are prioritized.

Types of BGP Relationships:

Encoding Business Relationships in BGP:

LOCAL_PREF is the primary tool for encoding relationship preferences:

• Customer routes get highest LOCAL_PREF: You're paid to carry this traffic; prefer it
• Peer routes get medium LOCAL_PREF: You've agreed to exchange traffic; use when available
• Transit routes get lowest LOCAL_PREF: You're paying; use only when necessary

This implements the customer > peer > transit preference hierarchy that drives Internet economics.

Outbound Policy Considerations:

1. To Transit Providers: Advertise only your prefixes and customer prefixes (you're selling transit)
2. To Peers: Advertise your prefixes and customer prefixes (mutual exchange)
3. To Customers: Advertise everything—your routes, peer routes, and other transit routes (full table or default)

Valley-Free Routing:

A BGP path should follow "valley-free" rules:

• Traffic goes UP (to transit), can go SIDEWAYS (between peers), then must go DOWN (to customer)
• Customer → Transit → Transit → Customer is valid
• Transit → Peer → Transit is NOT valid (you'd be providing free transit via peering)

Violating valley-free usually indicates a route leak.

Designing the AS edge involves selecting an architecture that balances redundancy, performance, manageability, and cost. Here are common patterns:

Pattern 1: Dual-Homed with Single ASBR per Provider

         ISP-A                ISP-B
           │                    │
         ASBR-1               ASBR-2
           │                    │
           └────── Core ─────────┘

Characteristics:

• Simple, common for small-medium enterprises
• Each ASBR connects to one ISP
• Single point of failure per upstream
• Route selection based on LOCAL_PREF per provider

Pattern 2: Dual-Homed with Dual ASBRs per Provider

         ISP-A                ISP-B
         ╱    ╲              ╱    ╲
     ASBR-1  ASBR-2      ASBR-3  ASBR-4
         ╲    ╱              ╲    ╱
           Core ──────────── Core

Characteristics:

• High redundancy (no single point of failure)
• More complex configuration
• Better load distribution
• Common for larger enterprises and service providers

Pattern 3: IXP Peering Architecture

        IXP Fabric
        ╱    │    ╲
    Peer1  Peer2  Peer3 ... PeerN
        ╲    │    ╱
         ASBR (at IXP)
              │
         Core Network

Characteristics:

• Single presence at IXP, multiple peering relationships
• Route servers simplify configuration
• Cost-effective for many peering sessions
• Colocation and cross-connect costs vs. individual peering circuits

We've thoroughly explored the critical demarcation points where Autonomous Systems connect to the wider Internet. Let's consolidate the essential knowledge:

Module Complete:

With this page, we've completed our exploration of the Interior vs. Exterior routing distinction. You now understand:

• How Autonomous Systems organize the Internet
• The characteristics of IGP protocols (RIP, OSPF, IS-IS, EIGRP)
• How BGP works as the Internet's exterior routing protocol
• How to select the right routing protocol for any scenario
• The architectural and operational considerations at AS boundaries

This knowledge forms the foundation for everything else in routing—from designing enterprise networks to understanding how traffic flows across the global Internet.