Skip to content

IXP_DETECTION_PROPOSAL.md

Latest commit

 

History

History
145 lines (119 loc) · 4.64 KB

IXP_DETECTION_PROPOSAL.md

File metadata and controls

145 lines (119 loc) · 4.64 KB

IXP/Peering Point Detection Proposal

Overview

This proposal outlines a systematic approach to identify Internet Exchange Points (IXPs) and peering locations in traceroute paths, building on ftr's existing ASN enrichment capabilities.

Motivation

  • Current traceroutes show ASN transitions but don't identify where peering occurs
  • Reverse DNS hints (e.g., "100.ae1.nrd1.equinix-sj.sonic.net") suggest IXP locations
  • Understanding peering points helps with network troubleshooting and path analysis

Research Findings

Available Data Sources

1. PeeringDB API (https://www.peeringdb.com/api/)

  • Status: Active, publicly accessible REST API
  • Provides: IXP locations, member ASNs, IP prefixes used by IXPs
  • Key endpoints:
    • /api/ix - IXP information
    • /api/netixlan - Network-IXP connections
    • /api/ixpfx - IXP IP prefixes
  • Example: Can query which ASNs peer at "Equinix SV1/SV5/SV10"

2. IXP IP Prefix Databases

  • PeeringDB maintains authoritative list of IP ranges used by IXPs
  • Packet Clearing House (PCH) provides additional IXP data
  • CAIDA's IXP dataset for research purposes

3. Reverse DNS Patterns

  • Many IXPs use identifiable hostname patterns:
    • Facility codes: equinix-sj, ams-ix, de-cix
    • Peering indicators: .ix., .peering., .exchange.
    • Geographic hints: city codes, facility names

Detection Methods

Method 1: IP Prefix Matching

1. Detect ASN transition: AS46375 → AS6453
2. Check if intermediate IPs fall within known IXP prefixes
3. Validate both ASNs are members of that IXP

Method 2: Reverse DNS Analysis

1. Parse rDNS for IXP/facility indicators
2. Cross-reference with PeeringDB facility names
3. Score confidence based on pattern matches

Method 3: RTT Analysis

1. Detect RTT anomalies at ASN boundaries
2. Sudden RTT drops often indicate local peering
3. Geographic validation using geolocation

Implementation Plan

Phase 1: Data Integration

  1. PeeringDB Client Module (src/ixp/peeringdb.rs)

    • Async client for PeeringDB API
    • Cache IXP prefixes and memberships
    • Periodic updates (configurable, default 24h)

  2. IXP Database (src/ixp/database.rs)

    • Store IXP prefixes as CIDR blocks
    • Index by ASN for quick membership lookups
    • Include facility names and locations

Phase 2: Detection Engine

  1. IXP Detector Service (src/ixp/detector.rs)

    pub struct IxpInfo {
    pub name: String,
    pub facility: Option<String>,
    pub location: String,
    pub member_asns: Vec<u32>,
    pub confidence: f32,  // 0.0 to 1.0
}

  2. Detection Algorithm:

    • For each ASN transition in traceroute
    • Check if IPs match IXP prefixes
    • Analyze rDNS patterns
    • Calculate confidence score

Phase 3: Integration

  1. Extend SegmentType:

    pub enum SegmentType {
    Lan,
    Isp,
    Ixp,        // New
    Transit,
    Destination,
    Unknown,
}

  2. Update TracerouteResult:

    • Add ixp_crossings: Vec<IxpCrossing>
    • Include IXP info in hop enrichment

  3. CLI Output:

    12 [ISP   ] 100.ae1.nrd1.equinix-sj.sonic.net (75.101.33.185) 5.580 ms [AS46375]
-- [IXP: Equinix SV1 - San Jose, AS46375 ↔ AS6453] --
13 [TRANSIT] 216.6.52.80 5.583 ms [AS6453 - TATA]

Phase 4: Configuration

  • --enable-ixp-detection: Enable IXP detection (default: false initially)
  • --ixp-cache-dir: Cache directory for PeeringDB data
  • --ixp-update-interval: How often to refresh IXP data

Validation Approach

  1. Test against known routes with confirmed IXP crossings
  2. Compare with looking glass data from major networks
  3. Validate against traIXroute results for accuracy baseline

Expected Accuracy

  • High confidence (>90%): When IP matches IXP prefix AND both ASNs are members
  • Medium confidence (60-90%): When rDNS patterns match known IXP facilities
  • Low confidence (<60%): Based solely on RTT analysis or geographic hints

Privacy & Performance Considerations

  • Cache PeeringDB data locally to minimize API calls
  • Respect rate limits (suggested: max 100 queries/hour)
  • Make IXP detection optional to avoid overhead

Future Enhancements

  1. BGP route views integration for validation
  2. Historical peering relationship tracking
  3. Anomaly detection for routing changes
  4. Integration with network monitoring tools

References

Target Release

Proposed for v0.7.0 or later, after v0.6.0 segment classification stabilizes.