Route Servers and Looking Glasses

Two tools quietly make the Internet work better than it should: route servers that turn the chaos of peering into something manageable, and looking glasses that answer the question every network operator dreads—"why can't they reach us?"

Neither tool touches your traffic directly. But without route servers, large-scale peering would drown in configuration complexity. Without looking glasses, routing problems would be black boxes you couldn't open.

The Math Problem Route Servers Solve

Imagine an Internet Exchange Point with 300 participating networks. If each network wanted to peer with every other network, that's 44,850 BGP sessions to configure and maintain. Even if each network only wants to peer with 50 others, that's still 50 separate sessions per network—50 configurations to maintain, 50 relationships to troubleshoot, 50 places where things can break.

Route servers collapse this complexity. Instead of 50 bilateral sessions, you configure one session to the route server. The route server maintains sessions with all participants and redistributes routes among them. Your one session gives you access to everyone who peers with the route server.

This isn't just convenience—it's the difference between "we can do this" and "we can't afford to do this" for smaller networks. A network with two engineers can't practically manage 200 BGP sessions. They can manage one.

How Route Servers Stay Invisible

Route servers have a strange requirement: they must be invisible in the routing path. When a route server redistributes a route from Network A to Network B, the route must look exactly like it came directly from Network A.

Why? Because BGP uses the AS_PATH to prevent loops and measure distance. If the route server added its own AS number to every path, routes would appear longer than they are (affecting path selection) and create apparent loops (causing route rejection).

So route servers use "transparent AS"—they redistribute routes without modifying the AS_PATH. The route server handles session management and policy enforcement, but from a routing perspective, it's not there.

This means actual traffic never touches the route server. When you send packets to a destination you learned through the route server, they go directly to the network that advertised the route. The route server only handles the control plane—the exchange of routing information—not the data plane.

What Route Servers Can and Cannot Do

Route servers excel at:

• Reducing configuration burden: one session instead of dozens or hundreds
• Accelerating peering: new peers become available immediately through the route server
• Conserving router resources: fewer BGP sessions means less memory and CPU
• Enabling selective peering: route servers respect filtering policies, so you can peer with some networks through the route server while excluding others

Route servers struggle with:

• High-volume relationships: major traffic flows often justify dedicated bilateral sessions with private interconnects
• Complex policies: some BGP features and policy requirements can only be expressed in bilateral sessions
• Availability dependencies: if the route server fails, you lose all routes learned through it

Most networks use both: route servers for broad peering with many networks, bilateral sessions for their most important relationships.

Looking Glasses: Seeing Through Other Networks' Eyes

Here's a scenario that haunts network operators: a customer reports they can reach your network fine, but users from another network can't reach them at all. The problem isn't on your network—it's in how that other network routes traffic to you. But you can't see their routing table. Or can you?

A looking glass is a web interface (and increasingly, an API) that lets you query another network's routers. You can see what routes they have for your prefixes, trace the path their packets would take to reach you, and examine their BGP table.

Common looking glass features:

• BGP route lookup: see what routes a network has for specific IP addresses, including the full AS_PATH and BGP attributes
• Traceroute: watch packets travel from their network toward your destination
• BGP summary: view peering relationships and session states
• Ping: test basic reachability from their perspective

This visibility is invaluable. If a network's looking glass shows no route to your prefix, you've found the problem. If it shows a route through an unexpected path, you've found a different problem. Either way, you're no longer guessing.

The Art of Using Looking Glasses

Effective troubleshooting with looking glasses requires checking multiple vantage points. A route might be present in one network but missing in another. The AS_PATH might differ between networks, revealing where routing information is being filtered or modified.

When investigating why some users can't reach you:

1. Check looking glasses from networks where users report problems
2. Verify your routes are present and the AS_PATH is correct
3. If routes are missing, trace backward—which network should be propagating your routes to them?
4. Check looking glasses at intermediate networks to find where propagation stops

When investigating suboptimal paths (traffic taking a longer route than necessary):

1. Check looking glasses from the source network
2. Compare the AS_PATH they're using to the path you'd prefer
3. Look for where the preferred path might be filtered or de-preferred

Major networks—Tier 1 providers, large content networks, significant regional carriers—typically operate looking glasses. This creates a mesh of vantage points around the Internet.

Route Server Looking Glasses

IXPs often provide looking glasses specifically for their route servers. These show:

• Which routes the route server has received from each participant
• Which prefixes are being advertised at the exchange
• BGP communities being used to signal policies
• Session states for all participants

If you're peering through a route server and your routes aren't reaching certain networks, the route server's looking glass can show whether the problem is in your advertisement to the route server, the route server's redistribution, or the receiving network's filtering.

Security and the Looking Glass Bargain

Operating a looking glass means exposing information about your network: topology details, peering relationships, routing policies. This visibility has value—to competitors doing market research, to attackers doing reconnaissance.

Looking glass operators mitigate risk by:

• Restricting commands to read-only operations
• Rate limiting queries to prevent abuse
• Running looking glass interfaces on dedicated systems, not production routers
• Limiting the depth of information exposed

Despite these concerns, many networks operate looking glasses as a contribution to the Internet community. Routing problems are easier to solve when networks can see each other's perspective. The looking glass bargain is: we show you our routing table, you show us yours, and we all troubleshoot faster.

Beyond Individual Looking Glasses

Several projects aggregate routing visibility at scale:

RIPE RIS and RouteViews collect BGP data from collectors worldwide, providing both real-time views and historical archives. You can see how global routing to your prefixes has changed over time.

BGP monitoring services watch for routing anomalies—hijacks, leaks, unexpected path changes—and alert operators when something looks wrong.

Distributed traceroute platforms let you run traceroutes from hundreds of locations without needing access to individual network looking glasses.

These tools complement individual looking glasses, providing broader coverage and historical context that single-network views can't offer.

Programmatic Access

Modern looking glasses increasingly offer APIs alongside web interfaces. This enables:

• Continuous monitoring of route presence across multiple networks
• Automated verification after routing changes
• Integration with alerting systems
• Data collection for traffic engineering decisions

What was once a manual troubleshooting tool becomes part of automated network operations.