diff --git a/README.md b/README.md index cc0c8fe..73bcb1a 100644 --- a/README.md +++ b/README.md @@ -4,33 +4,44 @@

PeerCortex

The AI-Powered Network Intelligence Platform

+

BGP Analysis · Peering Intelligence · RPKI Validation · ASPA Verification · Network Health Checks

+ GitHub Stars + MIT License + Live Demo + MCP Server + TypeScript + Ollama + Self-hosted PeeringDB RIPE Stat BGP - MCP Server - Ollama - Self-hosted - TypeScript - MIT License - Live Demo + Docker + Node.js 20+

+
+

- 🌐 Live Demo β†’ peercortex.org + Live Demo at peercortex.org +  •  + Quick Start +  •  + MCP Tools +  •  + Dashboard +  •  + Architecture

+
+

- AI-powered network intelligence. Query PeeringDB, analyze BGP, monitor RPKI,
- find peering partners β€” all from Claude Code or any MCP client. 100% local. + PeerCortex Dashboard Overview β€” AS199121 Analysis

---- - -

- PeerCortex Demo -

+

PeerCortex dashboard analyzing AS199121 β€” network overview, announced prefixes, RPKI compliance, and more

--- @@ -38,337 +49,378 @@ - [What is PeerCortex?](#what-is-peercortex) - [The Problem](#the-problem) -- [Features](#features) - - [ASN Intelligence](#-asn-intelligence) - - [Peering Partner Discovery](#-peering-partner-discovery) - - [BGP Analysis & Anomaly Detection](#-bgp-analysis--anomaly-detection) - - [RPKI Monitoring & Compliance](#-rpki-monitoring--compliance) - - [Network Comparison](#-network-comparison) - - [Report Generation](#-report-generation) +- [Web Dashboard](#web-dashboard) + - [Network Overview](#network-overview) + - [Announced Prefixes](#announced-prefixes) + - [RPKI Compliance](#rpki-compliance) + - [Network Health Report](#network-health-report) + - [RIPE Atlas Probes](#ripe-atlas-probes) + - [ASPA Status](#aspa-status) + - [ASPA Deep Analysis](#aspa-deep-analysis) + - [bgproutes.io Integration](#bgproutesio-integration) + - [Routing Overview](#routing-overview) + - [WHOIS Details](#whois-details) + - [Network Compare](#network-compare) + - [Peering Partner Finder](#peering-partner-finder) - [MCP Server Tools](#mcp-server-tools) - [Claude Code Integration](#claude-code-integration) +- [API Reference](#api-reference) - [Data Sources](#data-sources) -- [Feature Comparison](#feature-comparison) -- [Architecture](#architecture) -- [Quick Start](#quick-start) +- [Self-Hosting Guide](#self-hosting-guide) + - [Docker Deployment](#option-1-docker-recommended) + - [Node.js Installation](#option-2-local-installation) + - [npx One-Liner](#option-3-npx-one-liner) - [Configuration](#configuration) -- [Privacy & Security](#privacy--security) +- [Architecture](#architecture) +- [Privacy and Security](#privacy-and-security) +- [ASPA Intelligence](#aspa-intelligence) +- [Feature Comparison](#feature-comparison) - [Roadmap](#roadmap) - [Contributing](#contributing) - [FAQ](#faq) - [Acknowledgments](#acknowledgments) -- [Ecosystem](#ecosystem) --- ## What is PeerCortex? -PeerCortex is an **MCP (Model Context Protocol) Server** that unifies six major network intelligence data sources into a single, AI-queryable interface for network engineers, peering coordinators, and NOC operators. +PeerCortex is a **self-hosted network intelligence platform** that unifies data from PeeringDB, RIPE Stat, bgp.he.net, bgproutes.io, RIPE Atlas, IRR databases, and RPKI validators into a single interface. It ships as two components: -Instead of switching between PeeringDB, RIPE Stat, bgp.he.net, Route Views, IRR databases, and RPKI validators β€” each with their own interfaces and query languages β€” PeerCortex lets you ask questions in **plain English** through Claude Code or any MCP-compatible client. +1. **Web Dashboard** ([peercortex.org](https://peercortex.org)) β€” A live, interactive dashboard for instant ASN analysis with 12+ modules covering network overview, RPKI compliance, ASPA verification, health scoring, routing analysis, and more. -A local **Ollama** instance provides AI analysis: ranking peering partners, detecting BGP anomalies, generating compliance reports, and drafting peering request emails. All inference runs on your machine. No data leaves your network. +2. **MCP Server** β€” A Model Context Protocol server that exposes 25+ tools for AI-powered network analysis through Claude Code or any MCP-compatible client. Local Ollama inference means no data leaves your machine. -**Who is this for?** +**Who uses PeerCortex?** -- **Network Engineers** who want instant answers from multiple data sources -- **Peering Coordinators** who need to find and evaluate peering partners -- **NOC Operators** who monitor BGP health and detect anomalies -- **Security Teams** who track RPKI compliance and route hijacks -- **Anyone** who works with Internet routing data and wants AI assistance +- **Network Engineers** who need a unified view across fragmented data sources +- **Peering Coordinators** who evaluate potential peering partners and track IXP presence +- **NOC Operators** who monitor BGP health, detect anomalies, and investigate incidents +- **Security Teams** who track RPKI/ASPA compliance and identify route leaks +- **RPKI Deployers** who need per-prefix validation status and coverage metrics +- **ASPA Early Adopters** who want to generate ASPA objects and verify provider declarations --- ## The Problem -Network operators juggle fragmented tools. Every task requires a different interface: +Network operators juggle fragmented tools. Every task requires a different interface, a different query language, and manual correlation of results: | Task | Without PeerCortex | With PeerCortex | |------|-------------------|-----------------| -| ASN lookup | Open PeeringDB, RIPE Stat, bgp.he.net in separate tabs | `"Give me the full picture for AS13335"` | -| Find peering partners | Manual PeeringDB search, filter by IX, check policies | `"Find peering partners at DE-CIX with open policy"` | -| Detect route leaks | Check RIPE RIS, cross-reference AS paths, manual analysis | `"Any BGP anomalies for 185.1.0.0/24?"` | -| RPKI compliance | Query Routinator, match against announced prefixes, calculate coverage | `"Generate an RPKI compliance report for AS13335"` | -| Compare networks | Open both ASNs on PeeringDB, manually compare IX/facility lists | `"Compare AS13335 and AS32934"` | -| Peering request | Look up contacts, check common IXs, write email from scratch | `"Draft a peering request to AS714 for DE-CIX Frankfurt"` | +| ASN lookup | Open PeeringDB, RIPE Stat, bgp.he.net in separate tabs | Single query, unified results | +| RPKI compliance check | Query Routinator, match against announced prefixes, calculate coverage | Per-prefix validation with coverage percentage | +| Health assessment | Check bogons, ROAs, IRR, blocklists, MANRS, rDNS, abuse contacts... manually | 13-check automated health score in seconds | +| ASPA readiness | Manual BGP path analysis, check RIPE DB for ASPA objects, identify providers | Auto-detected providers with ready-to-submit ASPA template | +| Find peering partners | Manual PeeringDB search, filter by IX, check policies one by one | AI-ranked results with common IX and facility overlap | +| Compare two networks | Open both ASNs on PeeringDB, manually compare IX/facility lists | Side-by-side comparison with overlap analysis | +| Detect route leaks | Check RIPE RIS, cross-reference AS paths, analyze manually | Real-time ASPA-based leak detection from 3,294 vantage points | -PeerCortex collapses these multi-step workflows into **single natural language queries**, backed by real data from authoritative sources. +PeerCortex collapses these multi-step workflows into single queries backed by real data from authoritative sources. --- -## Features +## Web Dashboard -### 1. ASN Intelligence +The PeerCortex web dashboard is a single-page application that performs comprehensive ASN analysis. Enter any ASN and get instant results across 12+ modules, all rendered in a dark-themed, information-dense layout designed for network operators. -Unified ASN lookup that queries PeeringDB, RIPE Stat, bgp.he.net, IRR databases, and RPKI validators in parallel, returning a comprehensive network profile. +**Try it now:** [peercortex.org/?asn=13335](https://peercortex.org/?asn=13335) -**What you get:** -- Network name, type, scope, and peering policy -- Announced prefix counts (IPv4 + IPv6) -- IX participation with connection speeds -- Facility/colocation presence -- IRR registration status (as-set, route objects) -- RPKI ROA coverage and validation summary -- Upstream providers and peer count -- Contact information for peering +--- -**Example:** -``` -You: Give me the full picture for AS13335 +### Network Overview -PeerCortex: Here's the comprehensive profile for AS13335 (Cloudflare, Inc.): +The Network Overview module combines data from **PeeringDB** and **RIPE Stat** into a single unified panel. At a glance you see: - Network Type: Content - Peering Policy: Open - Scope: Global - Prefixes: 1,200+ IPv4, 200+ IPv6 - IXs: 290+ exchanges worldwide - Facilities: 320+ data centers - RPKI Coverage: 99.8% (all prefixes covered by ROAs) - IRR: AS-CLOUDFLARE registered in RADB - ... -``` +- **Network identity**: ASN, name, organization, network type (NSP, Content, Enterprise, etc.) +- **Peering policy**: Open, Selective, Restrictive, or No Policy listed +- **Scope**: Regional, National, Continental, or Global +- **Contact information**: Peering email, NOC phone, policy URL +- **Registration metadata**: RIR allocation, holder name, registration date +- **Peer and neighbor counts**: Upstream providers, downstream customers, lateral peers +- **IX participation summary**: Total exchanges, total facilities +- **BGP visibility**: Percentage of RIPE RIS collectors seeing the AS -### 2. Peering Partner Discovery +This module pulls from PeeringDB's REST API v2 for the network profile and RIPE Stat's AS Overview and ASN Neighbours data calls for routing context. The result is a single panel that replaces opening three different websites. -AI-ranked peering partner recommendations based on common IX presence, facility overlap, policy compatibility, and network type complementarity. +--- -**What you get:** -- Ranked list of potential peering partners -- Match score with reasoning -- Common IXs and facilities -- Peering policy compatibility -- Contact information -- Draft peering request emails +### Announced Prefixes -**Example:** -``` -You: Find peering partners for AS13335 at DE-CIX Frankfurt with open policy +The Announced Prefixes module shows every prefix originated by the ASN, broken down by address family: -PeerCortex: Found 47 networks at DE-CIX Frankfurt with open peering policy. -Top matches for AS13335: +- **IPv4 prefix count** with individual prefix listings +- **IPv6 prefix count** with individual prefix listings +- **Prefix size distribution**: /8 through /24 for IPv4, /32 through /48 for IPv6 +- **First seen / last seen timestamps** from RIPE RIS collectors - 1. AS32934 (Facebook) β€” Score: 92/100 - Common IXs: DE-CIX Frankfurt, AMS-IX, LINX - Common Facilities: Equinix FR5, Interxion FRA - Policy: Open | Type: Content - Why: Major content network, high traffic overlap potential +Data is sourced from RIPE Stat's Announced Prefixes data call, which reflects the current global routing table as observed by RIPE RIS route collectors distributed worldwide. - 2. AS15169 (Google) β€” Score: 88/100 - Common IXs: DE-CIX Frankfurt, AMS-IX, LINX, JPNAP - ... -``` +--- -### 3. BGP Analysis & Anomaly Detection +### RPKI Compliance -Real-time BGP analysis using data from RIPE Stat RIS collectors, Route Views, and bgp.he.net. Detects route leaks, BGP hijacks, MOAS conflicts, and path anomalies. +The RPKI Compliance module validates every announced prefix against ROA (Route Origin Authorization) data: -**What you get:** -- AS path analysis and diversity metrics -- Route origin validation -- Anomaly detection with severity levels -- Route leak identification -- BGP hijack alerts -- MOAS (Multiple Origin AS) conflict detection -- Prefix visibility reports -- AI-generated routing assessment +- **Per-prefix validation status**: Valid, Invalid, or Not Found +- **Overall coverage percentage**: What fraction of prefixes have valid ROAs +- **Max-length analysis**: Flags over-permissive max-length settings that could enable sub-prefix hijacking +- **Color-coded results**: Green for valid, red for invalid, yellow for not covered -**Example:** -``` -You: Are there any BGP anomalies for 185.1.0.0/24 right now? +PeerCortex queries RPKI validators (local Routinator if available, RIPE RPKI validator as fallback) to perform origin validation for each prefix-ASN pair. This gives operators an immediate view of their RPKI deployment completeness. -PeerCortex: BGP analysis for 185.1.0.0/24: +--- - Origin AS: AS47541 - Path Diversity: 12 unique paths from 24 collectors - Visibility: 98.5% (seen by 394/400 RIS peers) - RPKI Status: Valid (ROA match: 185.1.0.0/24, max /24, AS47541) +### Network Health Report - Anomalies Detected: None - No route leaks, hijacks, or MOAS conflicts detected. - Routing appears stable and healthy. -``` +

+ PeerCortex Health Report β€” 13 automated validation checks +

-``` -You: Show me all route leaks involving my prefixes in the last 7 days +

Network Health Report with 13 automated checks and a weighted health score

-PeerCortex: Analyzing BGP updates for your prefixes over the last 7 days... +The Network Health Report is one of the most comprehensive features in PeerCortex. It runs **13 independent validation checks** in parallel and calculates a weighted health score from 0 to 100: - ALERT: 2 route leak events detected +| # | Check | What It Validates | Weight | +|---|-------|-------------------|--------| +| 1 | **Bogon Detection** | Checks all announced prefixes against RFC 5735/6890 bogon ranges (10.0.0.0/8, 192.168.0.0/16, etc.) and flags bogon ASNs (AS0, AS23456, private range 64512-65534) | High | +| 2 | **ROA Completeness** | RPKI ROA coverage across all announced prefixes with per-prefix validation | High | +| 3 | **IRR Consistency** | Cross-references BGP-announced origins against IRR (RIPE DB, RADB) route objects to find mismatches | Medium | +| 4 | **Blocklist Check** | Queries Spamhaus DROP, Team Cymru bogon lists, and RIPE Stat blocklist data for listed prefixes | High | +| 5 | **MANRS Compliance** | Checks MANRS Observatory for participation status and conformance score | Medium | +| 6 | **BGP Visibility** | Measures how many RIPE RIS route collectors see the ASN's prefixes (target: >90%) | Medium | +| 7 | **Reverse DNS** | Checks rDNS delegation consistency for announced prefixes via RIPE Stat | Low | +| 8 | **Abuse Contact** | Verifies that a valid abuse contact email is registered in the RIPE DB | Medium | +| 9 | **Resource Certificate** | Validates RPKI resource certificate existence via RIPE Stat | Medium | +| 10 | **IX Route Servers** | Checks whether the network peers with route servers at its IXPs (via PeeringDB) | Low | +| 11 | **BGP Communities** | Analyzes BGP community usage from RIPE RIS looking glass data | Low | +| 12 | **Geolocation Consistency** | Cross-references announced prefix geolocation with registered RIR data | Low | +| 13 | **IRR Object Quality** | Evaluates the completeness and currency of IRR aut-num and as-set objects | Medium | - 1. [HIGH] 2026-03-22T14:32:00Z β€” 203.0.113.0/24 - Leaked by AS64496 via AS64497 - Expected path: AS64496 β†’ AS64498 β†’ origin - Observed path: AS64496 β†’ AS64497 β†’ AS64499 β†’ origin - Duration: 23 minutes - Impact: Partial traffic rerouting through unexpected path - ... -``` +Each check runs independently and returns a pass/warning/fail status. The weighted score gives operators a single number that summarizes the overall health of their routing posture. Detailed per-check results let you drill into specific issues. -### 4. RPKI Monitoring & Compliance +All validation data is fetched in parallel from RIPE Stat, RIPE DB, PeeringDB, MANRS Observatory, IRR Explorer (NLNOG), and Spamhaus to minimize wait times. -Comprehensive RPKI validation and compliance monitoring. Validates prefix-origin pairs, generates compliance reports, and identifies networks at IXs without RPKI coverage. +--- -**What you get:** -- Prefix-origin RPKI validation (valid/invalid/not-found) -- ROA coverage percentage for an ASN -- Compliance reports with recommendations -- IX-level RPKI coverage analysis -- Comparison with industry benchmarks -- Step-by-step remediation guidance +### RIPE Atlas Probes -**Example:** -``` -You: Generate an RPKI compliance report for AS13335 +The RIPE Atlas Probes module shows all RIPE Atlas measurement probes hosted within the ASN: -PeerCortex: RPKI Compliance Report β€” AS13335 (Cloudflare, Inc.) +- **Total probes**: Count of probes registered in the ASN +- **Connected probes**: How many are currently online and participating in measurements +- **Anchor probes**: Whether the ASN hosts any RIPE Atlas anchors (dedicated measurement infrastructure) +- **Probe details**: Individual probe IDs, status, IPv4/IPv6 addresses, country codes - Overall Coverage: 99.8% - Total Announced Prefixes: 1,432 - RPKI Valid: 1,429 (99.8%) - RPKI Invalid: 0 (0.0%) - Not Covered: 3 (0.2%) +This data comes directly from the RIPE Atlas API. Having Atlas probes in your network is a sign of good Internet citizenship and enables you to run measurements from within your own infrastructure. - Uncovered Prefixes: - - 198.51.100.0/24 (recently announced, ROA pending) - - 2001:db8:1::/48 (experimental prefix) - - 2001:db8:2::/48 (experimental prefix) +--- - Recommendations: - 1. Create ROAs for the 3 uncovered prefixes - 2. All ROAs have appropriate max-length settings - 3. RPKI-invalid route filtering is recommended on all sessions - ... -``` +### ASPA Status -``` -You: Which ASNs at AMS-IX don't have RPKI? +

+ PeerCortex ASPA Status β€” Provider Detection and ASPA Template +

-PeerCortex: RPKI Coverage Analysis β€” AMS-IX +

ASPA Status with auto-detected upstream providers and a ready-to-submit ASPA object template

- Total Participants: 932 - With RPKI Coverage: 714 (76.6%) - Without RPKI: 218 (23.4%) +The ASPA (Autonomous System Provider Authorization) Status module performs BGP path analysis to determine the ASN's upstream providers and generates a recommended ASPA object: - Largest uncovered networks: - - AS64496 (Example ISP) β€” 450 prefixes, 0% RPKI coverage - - AS64497 (Example Transit) β€” 230 prefixes, 0% RPKI coverage - ... -``` +- **Provider detection**: Analyzes BGP paths from RIPE RIS looking glass data and ASN neighbor relationships to identify upstream transit providers +- **Provider list**: Each detected provider shown with ASN and name +- **ASPA object existence check**: Queries RIPE DB for existing ASPA object registrations +- **Recommended ASPA template**: A pre-formatted ASPA object ready for submission to the RIPE DB, listing all detected providers with AFI (Address Family Identifier) for both IPv4 and IPv6 +- **Sample AS paths**: Shows real BGP paths with provider identification marked -### 5. Network Comparison +The module fetches data from RIPE Stat's Looking Glass and ASN Neighbours endpoints, then cross-references with RIPE DB to check for existing ASPA registrations. Provider names are resolved via RIPE Stat's AS Overview API. -Side-by-side comparison of two autonomous systems across all dimensions: size, IX presence, facility overlap, peering policy, RPKI deployment, and geographic coverage. +This module is essential for operators preparing to deploy ASPA, as it automates the provider discovery step that would otherwise require manual BGP path analysis. -**What you get:** -- Side-by-side metrics table -- Common and unique IXs -- Common and unique facilities -- Peering potential score -- AI-generated comparison narrative -- Peering opportunity identification +--- -**Example:** -``` -You: Compare AS13335 and AS32934 β€” where do they peer? +### ASPA Deep Analysis -PeerCortex: Network Comparison β€” AS13335 (Cloudflare) vs AS32934 (Facebook) +

+ PeerCortex ASPA Deep Analysis β€” RFC-compliant verification +

- Metric | AS13335 (Cloudflare) | AS32934 (Facebook) - ──────────────────────────────────────────────────────────── - Type | Content | Content - Policy | Open | Selective - IPv4 Prefixes | 1,200+ | 800+ - IPv6 Prefixes | 200+ | 150+ - IX Count | 290+ | 180+ - Facility Count | 320+ | 60+ - RPKI Coverage | 99.8% | 99.5% +

ASPA Deep Analysis with readiness score gauge, upstream/downstream verification, valley detection, and path verification table

- Common IXs (142): - DE-CIX Frankfurt, AMS-IX, LINX, France-IX, JPNAP, Equinix IX, - HKIX, SIX Seattle, Any2 Los Angeles, TorIX, ... +The ASPA Deep Analysis module goes beyond basic provider detection to provide a full RFC 9582-compliant verification: - Unique to Cloudflare (148): - NIX.CZ, BKNIX, KINX, MIX-IT, ... +- **Readiness Score Gauge**: A 0-100 score indicating how well the ASN's provider declarations align with observed BGP paths. Higher scores mean better ASPA compliance. - Unique to Facebook (38): - ... +- **Upstream Verification**: Validates each detected upstream provider against ASPA declarations. Shows which providers are properly declared and which are missing from the ASPA object. - These networks peer extensively at 142 common IXs worldwide. -``` +- **Downstream Verification**: Checks downstream customer relationships for consistency with ASPA declarations from the customer side. -### 6. Report Generation +- **Valley Detection**: Implements the valley-free routing principle from RFC 9582. A "valley" in an AS path (customer-to-provider followed by provider-to-customer through a different provider) indicates a route leak. The module scans all observed BGP paths for valley violations. -Generate presentation-ready reports suitable for NANOG, RIPE, DENOG, or internal meetings. Multiple report types in Markdown, JSON, or plain text. +- **AS_SET Flagging**: Identifies paths containing AS_SET aggregation, which can obscure the true origin AS and complicate ASPA validation. AS_SETs are a known challenge for ASPA deployment. -**Report types:** -- **Peering Readiness** β€” Evaluates an ASN's readiness for peering -- **RPKI Compliance** β€” Full RPKI deployment status with remediation steps -- **Network Comparison** β€” Detailed two-network comparison -- **BGP Health** β€” Routing health assessment with anomaly history -- **IX Analysis** β€” Internet Exchange participation analysis +- **Provider Audit**: Compares detected providers (from BGP path analysis) against declared providers (from ASPA objects). Flags: + - **Missing declarations**: Providers seen in BGP paths but not declared in the ASPA object + - **Extra declarations**: Providers declared in the ASPA object but not observed in current BGP paths -**Example:** -``` -You: Generate a peering readiness report for AS13335 +- **Path Verification Table**: Shows individual BGP paths with per-hop ASPA validation results. Each hop is marked as valid (provider relationship authorized), invalid (unauthorized), or unknown (no ASPA object available). -PeerCortex: # Peering Readiness Report β€” AS13335 (Cloudflare, Inc.) +- **RPKI Coverage**: Shows the percentage of prefixes with valid ROAs, providing context for how much of the ASN's address space is protected by the RPKI foundation that ASPA builds upon. - ## Executive Summary - AS13335 demonstrates excellent peering readiness with global IX presence, - open peering policy, and near-complete RPKI coverage... +The deep analysis endpoint (`/api/aspa/verify`) fetches data from RIPE Stat Looking Glass (up to 5 sample prefixes), ASN Neighbours, and RIPE DB. It processes all RRC (Route Collector) paths, extracts provider relationships, and applies the RFC 9582 Section 6 validation algorithm. - ## Key Findings - - Present at 290+ IXs across 6 continents - - Open peering policy with clear documentation - - 99.8% RPKI coverage - - Active PeeringDB profile with up-to-date contact info - ... -``` +--- + +### bgproutes.io Integration + +PeerCortex integrates with [bgproutes.io](https://bgproutes.io), a BGP monitoring platform with **3,294 vantage points** worldwide: + +- **Vantage point count**: Shows how many BGP collectors are available and their geographic distribution +- **RIB entries**: Routing Information Base entries for the ASN's prefixes as seen from selected vantage points +- **ROV status per route**: RPKI Route Origin Validation status (Valid, Invalid, Unknown) for each prefix from each vantage point +- **ASPA status per route**: ASPA validation status for each route, providing a real-world view of ASPA deployment effectiveness +- **AS path data**: Full AS paths as observed from vantage points, useful for debugging routing issues + +The bgproutes.io integration provides a perspective from outside the RIPE RIS collector network. With over 3,000 vantage points, it offers broader coverage of global routing state than any single collector project. + +--- + +### Routing Overview + +

+ PeerCortex Routing Overview β€” Neighbors, IXPs, and Facilities +

+ +

Routing overview showing neighbor relationships, IX participation with speeds, and facility presence

+ +The Routing Overview section combines three related views: + +**Neighbor Relationships** +- **Upstream providers** (left neighbors): Transit providers the ASN purchases from +- **Downstream customers** (right neighbors): Networks that purchase transit from this ASN +- **Lateral peers**: Networks with a peering (non-transit) relationship +- Each neighbor shown with ASN, name, relationship type, and relative power metric + +**IX Participation** +- Complete list of Internet Exchanges where the ASN is present +- Connection speed per IX (10G, 100G, 400G, etc.) +- IPv4 and IPv6 peering addresses at each IX +- City/location of each exchange +- Sorted by connection speed (largest first) + +**Facility Presence** +- Data centers and colocation facilities where the ASN has a physical presence +- Facility name, city, and country +- Useful for identifying interconnection opportunities + +Neighbor data comes from RIPE Stat's ASN Neighbours endpoint. IX and facility data come from PeeringDB's netixlan and netfac endpoints. + +--- + +### WHOIS Details + +The WHOIS module provides structured WHOIS information for the ASN: + +- Full WHOIS record from the relevant RIR (RIPE, ARIN, APNIC, LACNIC, AFRINIC) +- Parsed and formatted for readability +- Registration and update timestamps +- Maintainer and source information + +Accessible via the `/api/whois` endpoint which queries the node-whois library against the appropriate WHOIS server. + +--- + +### Network Compare + +The Network Compare module enables side-by-side comparison of two autonomous systems: + +- **Metrics table**: Prefix counts (IPv4/IPv6), IX count, facility count, peer count, RPKI coverage for both ASNs +- **Common IXPs**: Internet Exchanges where both networks are present (peering opportunities) +- **Unique IXPs**: Exchanges where only one of the two networks is present +- **Common facilities**: Data centers where both networks have a presence +- **Peering potential score**: Based on IX overlap, facility overlap, and policy compatibility + +Enter any second ASN in the compare input field on the dashboard to trigger a side-by-side analysis. The data is fetched in parallel for both ASNs from PeeringDB and RIPE Stat. + +--- + +### Peering Partner Finder + +The Peering Partner Finder discovers networks that share common infrastructure: + +- Filter by IX presence, peering policy, network type, or geographic region +- Results ranked by overlap score (common IXPs and facilities) +- Direct links to PeeringDB profiles +- Contact information for peering coordination + +Available through the MCP server's `peering` tool with AI-powered ranking via Ollama. --- ## MCP Server Tools -PeerCortex exposes six tools via the Model Context Protocol: +PeerCortex exposes **25+ tools** via the Model Context Protocol. Each tool accepts structured input validated by Zod schemas and returns typed JSON responses. + +### Core Tools | Tool | Description | Primary Data Sources | |------|-------------|---------------------| -| `lookup` | ASN, prefix, and IX lookups with unified results | PeeringDB, RIPE Stat, bgp.he.net, IRR, RPKI | +| `lookup` | Unified ASN, prefix, and IX lookups | PeeringDB, RIPE Stat, bgp.he.net, IRR, RPKI | | `peering` | Peering partner discovery and match scoring | PeeringDB, Ollama | | `bgp` | BGP path analysis and anomaly detection | RIPE Stat, Route Views, bgp.he.net | | `rpki` | RPKI validation and compliance monitoring | Routinator, RIPE RPKI Validator | | `compare` | Side-by-side network comparison | PeeringDB, RIPE Stat, RPKI | | `report` | Generate comprehensive analysis reports | All sources + Ollama | -| `measure_rtt` | RTT measurement via RIPE Atlas probes | RIPE Atlas | -| `traceroute` | Traceroute with ASN annotation and IXP detection | RIPE Atlas, RIPE Stat | -| `upstream_analysis` | Identify and evaluate upstream transit providers | CAIDA, bgp.he.net, RIPE Stat | -| `transit_diversity` | Assess redundancy and single points of failure | CAIDA, Route Views | -| `peering_vs_transit` | Cost/latency comparison of peering vs. transit | PeeringDB, RIPE Stat | -| `as_graph` | AS-level topology graph with relationship types | CAIDA, bgproutes.io | -| `submarine_cables` | Submarine cable lookup by region or landing point | TeleGeography, PeeringDB | -| `facility_analysis` | Colocation presence and interconnection opportunities | PeeringDB | -| `ix_traffic` | IX traffic statistics and historical trends | DE-CIX, AMS-IX, LINX | -| `ix_comparison` | Side-by-side comparison of multiple IXes | DE-CIX, AMS-IX, LINX | -| `port_utilization` | Port utilization analysis with upgrade recommendations | PeeringDB, IX APIs | -| `hijack_detection` | Detect BGP hijacks via RPKI ROV and MOAS analysis | bgproutes.io, RIPE Stat | -| `route_leak_detection_aspa` | ASPA-based route leak detection | bgproutes.io | -| `bogon_check` | Bogon prefix and bogon ASN detection | RIPE Stat, IANA | -| `blacklist_check` | IP/prefix/ASN blacklist and reputation checks | Spamhaus, Team Cymru | -| `reverse_dns` | Batch reverse DNS with FCrDNS verification | Cloudflare DoH | -| `delegation_check` | DNS delegation and DNSSEC validation | Cloudflare DoH | -| `whois_lookup` | Structured WHOIS for IPs, ASNs, and domains | RIPE DB, WHOIS | -| `atlas_create_measurement` | Create RIPE Atlas measurements | RIPE Atlas | -| `atlas_get_results` | Retrieve and summarize measurement results | RIPE Atlas | -| `atlas_search_probes` | Search probes by ASN, country, prefix, or anchor | RIPE Atlas | -Each tool accepts structured input validated by Zod schemas and returns typed JSON responses. +### RIPE Atlas Tools + +| Tool | Description | +|------|-------------| +| `measure_rtt` | RTT measurement via RIPE Atlas probes | +| `traceroute` | Traceroute with ASN annotation and IXP detection | +| `atlas_create_measurement` | Create custom RIPE Atlas measurements | +| `atlas_get_results` | Retrieve and summarize measurement results | +| `atlas_search_probes` | Search probes by ASN, country, prefix, or anchor status | + +### Transit and Topology Tools + +| Tool | Description | +|------|-------------| +| `upstream_analysis` | Identify and evaluate upstream transit providers | +| `transit_diversity` | Assess redundancy and single points of failure | +| `peering_vs_transit` | Cost/latency comparison of peering vs. transit paths | +| `as_graph` | AS-level topology graph with relationship types | +| `submarine_cables` | Submarine cable lookup by region or landing point | + +### IX and Facility Tools + +| Tool | Description | +|------|-------------| +| `facility_analysis` | Colocation presence and interconnection opportunities | +| `ix_traffic` | IX traffic statistics and historical trends | +| `ix_comparison` | Side-by-side comparison of multiple IXes | +| `port_utilization` | Port utilization analysis with upgrade recommendations | + +### Security and Validation Tools + +| Tool | Description | +|------|-------------| +| `hijack_detection` | Detect BGP hijacks via RPKI ROV and MOAS analysis | +| `route_leak_detection_aspa` | ASPA-based route leak detection | +| `bogon_check` | Bogon prefix and bogon ASN detection | +| `blacklist_check` | IP/prefix/ASN blacklist and reputation checks | + +### DNS and WHOIS Tools + +| Tool | Description | +|------|-------------| +| `reverse_dns` | Batch reverse DNS with FCrDNS verification | +| `delegation_check` | DNS delegation and DNSSEC validation | +| `whois_lookup` | Structured WHOIS for IPs, ASNs, and domains | --- ## Claude Code Integration -Add PeerCortex to your Claude Code configuration: +Add PeerCortex to your Claude Code MCP configuration (`~/.claude.json` or project `.claude.json`): ```json { @@ -387,283 +439,223 @@ Add PeerCortex to your Claude Code configuration: ### Example Conversations -Once configured, you can interact with PeerCortex naturally through Claude Code: +Once configured, interact with PeerCortex naturally through Claude Code: ``` You: Give me the full picture for AS13335 -Claude: I'll look up comprehensive information for AS13335 using PeerCortex... +Claude: [Calls lookup tool with asn=13335] -[Calls lookup tool with asn=13335] - -Here's the complete profile for AS13335 (Cloudflare, Inc.): - -Network Overview: - - Name: Cloudflare, Inc. - - Type: Content - - Peering Policy: Open - - Scope: Global - - Website: cloudflare.com +Here's the comprehensive profile for AS13335 (Cloudflare, Inc.): + Network Type: Content | Policy: Open | Scope: Global + Prefixes: 1,200+ IPv4, 200+ IPv6 + IXs: 290+ exchanges worldwide + Facilities: 320+ data centers + RPKI Coverage: 99.8% ... ``` ``` -You: Find peering partners for AS13335 at DE-CIX with open policy +You: Find peering partners for AS13335 at DE-CIX Frankfurt with open policy -Claude: Let me search for networks at DE-CIX with open peering policy -that would be good matches for Cloudflare... +Claude: [Calls peering tool] -[Calls peering tool with asn=13335, ix="DE-CIX Frankfurt", policy="open"] - -I found 47 potential peering partners at DE-CIX Frankfurt. Here are the -top matches ranked by compatibility... -``` - -``` -You: Are there any BGP anomalies for 185.1.0.0/24 right now? - -Claude: I'll analyze the current BGP routing state for that prefix... - -[Calls bgp tool with resource="185.1.0.0/24", include_anomalies=true] - -Good news β€” no anomalies detected for 185.1.0.0/24. The prefix is -currently announced by AS47541 with stable routing... +Found 47 networks at DE-CIX Frankfurt with open peering policy. +Top matches: + 1. AS32934 (Meta) β€” Score: 92/100 + Common IXs: DE-CIX Frankfurt, AMS-IX, LINX + 2. AS15169 (Google) β€” Score: 88/100 + ... ``` ``` You: Compare AS13335 and AS32934 β€” where do they peer? -Claude: Let me pull up a side-by-side comparison of Cloudflare and Facebook... +Claude: [Calls compare tool] -[Calls compare tool with asn1=13335, asn2=32934] - -Here's a detailed comparison of the two networks. They peer at -142 common Internet Exchanges worldwide... +Cloudflare vs Meta: They peer at 142 common Internet Exchanges worldwide. +Common IXs: DE-CIX Frankfurt, AMS-IX, LINX, France-IX, JPNAP, ... ``` ``` You: Generate an RPKI compliance report for AS13335 -Claude: I'll generate a comprehensive RPKI compliance report... +Claude: [Calls rpki tool] -[Calls rpki tool with asn=13335, include_recommendations=true] - -Here's the RPKI compliance report for Cloudflare. They have 99.8% -coverage with only 3 uncovered prefixes... +RPKI Compliance Report β€” AS13335 (Cloudflare, Inc.) + Overall Coverage: 99.8% + RPKI Valid: 1,429 | Invalid: 0 | Not Covered: 3 + Recommendation: Create ROAs for the 3 uncovered prefixes ``` ``` -You: Which ASNs at AMS-IX don't have RPKI? +You: Analyze ASPA readiness for AS199121 -Claude: Let me analyze RPKI coverage across AMS-IX participants... +Claude: [Calls aspa tool] -[Calls rpki tool for IX coverage analysis] - -Out of 932 AMS-IX participants, 218 (23.4%) don't have RPKI -coverage for their announced prefixes... +AS199121 has no registered ASPA object. Based on BGP path analysis, +detected upstream providers: AS174 (Cogent), AS3356 (Lumen). +Generated ASPA template ready for RIPE DB submission. ``` ``` -You: Show me all route leaks involving my prefixes in the last 7 days +You: Trace the path from AS32934 to AS13335 and show latency -Claude: I'll scan BGP update data for route leak events... +Claude: [Calls traceroute tool] -[Calls bgp tool with anomaly detection] - -I found 2 route leak events in the last 7 days affecting your prefixes... +Traceroute from AS32934 to AS13335: 8 hops, avg RTT 4.2ms. +Path crosses DE-CIX Frankfurt at hop 4. No congestion detected. ``` -``` -You: Draft a peering request email to AS714 for DE-CIX Frankfurt +--- -Claude: I'll draft a professional peering request to Apple... +## API Reference -[Calls peering tool to generate email draft] +The PeerCortex web dashboard is powered by a REST API. All endpoints return JSON. -Here's a ready-to-send peering request email to Apple's peering team -for establishing peering at DE-CIX Frankfurt... +### Endpoints + +| Endpoint | Method | Parameters | Description | +|----------|--------|------------|-------------| +| `/api/lookup` | GET | `asn` | Unified ASN lookup combining PeeringDB, RIPE Stat, RPKI, RIPE Atlas, and bgp.he.net | +| `/api/validate` | GET | `asn` | Network Health Report β€” runs 13 validation checks and returns weighted health score | +| `/api/aspa` | GET | `asn` | ASPA status β€” detects upstream providers, checks for ASPA objects, generates template | +| `/api/aspa/verify` | GET | `asn` | ASPA Deep Analysis β€” RFC 9582 compliant verification with path validation | +| `/api/bgproutes` | GET | `asn` or `prefix` | bgproutes.io integration β€” vantage points, RIB entries, ROV/ASPA status | +| `/api/compare` | GET | `asn1`, `asn2` | Side-by-side network comparison | +| `/api/peers/find` | GET | `asn`, `ix`, `policy` | Peering partner discovery | +| `/api/prefix/detail` | GET | `prefix` | Detailed prefix information | +| `/api/ix/detail` | GET | `ix_id` | Internet Exchange details | +| `/api/topology` | GET | `asn` | AS-level topology data | +| `/api/whois` | GET | `query` | WHOIS lookup | +| `/api/health` | GET | β€” | API health check (uptime, version, bgproutes status) | + +### Response Format + +All API responses follow a consistent structure: + +```json +{ + "meta": { + "query": "AS199121", + "duration_ms": 2340, + "timestamp": "2026-03-26T12:00:00.000Z" + }, + "asn": 199121, + "name": "Example Network", + "...": "endpoint-specific data" +} ``` -``` -You: Trace the path from AS32934 (Meta) to Cloudflare (AS13335) and show latency +### Rate Limiting -Claude: I'll create a RIPE Atlas traceroute from Meta's network to Cloudflare... +The API enforces rate limiting of **60 requests per minute per IP address**. Responses are cached in memory with configurable TTL (default: 5 minutes for lookups, 10 minutes for ASPA data). -[Calls traceroute tool with target="1.1.1.1", sourceAsn=32934] +### Caching -The traceroute from AS32934 to AS13335 shows 8 hops with an average -RTT of 4.2ms. The path crosses DE-CIX Frankfurt at hop 4, where both -networks are present. No IXP-level congestion detected... -``` - -``` -You: Detect route leaks using ASPA validation for prefixes of AS13335 - -Claude: I'll check all Cloudflare prefixes for ASPA validation failures... - -[Calls route_leak_detection_aspa tool with asn=13335] - -Checked 1,432 prefixes for AS13335 (Cloudflare). No active route leaks -detected via ASPA validation. AS13335 has ASPA objects registered for -all upstream providers. 2 historical leak events found from the past -90 days, both resolved within 15 minutes... -``` - -``` -You: Show IX traffic trends at DE-CIX Frankfurt for the last 12 months - -Claude: I'll fetch DE-CIX Frankfurt traffic statistics with monthly granularity... - -[Calls ix_traffic tool with ix="de-cix-frankfurt", period="12m", granularity="monthly"] - -DE-CIX Frankfurt traffic over the last 12 months: - Current Peak: 14.2 Tbps - Average: 8.7 Tbps - Year-over-Year Growth: +18.4% - Connected Networks: 1,100+ - Monthly trend shows consistent growth with seasonal peaks in Q4... -``` - -``` -You: What would change if AS32934 (Meta) peered directly with AS13335 (Cloudflare) -instead of using transit? - -Claude: Let me analyze the current path and potential direct peering benefits... - -[Calls peering_vs_transit tool with sourceAsn=32934, targetAsn=13335] - -Current path: AS32934 β†’ AS174 (Cogent) β†’ AS13335 (3 hops, ~12ms RTT) -With direct peering at DE-CIX Frankfurt: AS32934 β†’ AS13335 (1 hop, ~2ms RTT) - -Both networks are present at 142 common IXes and 28 common facilities. -Estimated RTT reduction: 10ms. Direct peering is strongly recommended -given the extensive IX overlap and open peering policies... -``` +| Data Type | Cache TTL | +|-----------|-----------| +| ASN Lookups | 5 minutes | +| ASPA Analysis | 10 minutes | +| Validation / Health | 5 minutes | +| General API responses | 5 minutes | --- ## Data Sources -| Source | URL | Data Provided | Update Frequency | -|--------|-----|---------------|------------------| -| **PeeringDB** | [peeringdb.com](https://www.peeringdb.com/) | Network info, IXs, facilities, contacts | User-maintained (near real-time) | -| **RIPE Stat** | [stat.ripe.net](https://stat.ripe.net/) | BGP state, prefixes, visibility, RPKI | Real-time (RIS collectors) | -| **bgp.he.net** | [bgp.he.net](https://bgp.he.net/) | Peers, upstreams, downstreams, prefixes | Multiple times daily | -| **Route Views** | [routeviews.org](https://www.routeviews.org/) | Global routing table, path diversity | Real-time (via RIPE Stat) | -| **IRR** | [rest.db.ripe.net](https://rest.db.ripe.net/) | Route objects, as-sets, WHOIS | Near real-time | -| **RPKI** | Local Routinator / RIPE RPKI | ROA validation, VRP list | Every ~10 minutes | -| **bgproutes.io** | [bgproutes.io](https://bgproutes.io/) | RIB entries, BGP updates, AS topology, RPKI ROV + ASPA validation | Real-time | -| **RIPE Atlas** | [atlas.ripe.net](https://atlas.ripe.net/) | Ping, traceroute, DNS, SSL measurements from global probes | On-demand | -| **CAIDA AS Rank** | [asrank.caida.org](https://asrank.caida.org/) | AS relationships, customer cones, rankings | Periodic | -| **IX Traffic** | DE-CIX, AMS-IX, LINX public APIs | IX traffic statistics and trends | Near real-time | -| **DNS-over-HTTPS** | Cloudflare/Google DoH | rDNS, delegation, DNSSEC verification | Real-time | +PeerCortex aggregates network intelligence from multiple authoritative sources. No data is fabricated or estimated β€” every data point comes from a real-time query to one of these sources: -All data is fetched directly from authoritative sources. PeerCortex caches responses locally in SQLite to reduce API calls and improve response times. +| Source | URL | Data Provided | Auth Required | +|--------|-----|---------------|---------------| +| **PeeringDB** | [peeringdb.com](https://www.peeringdb.com/) | Network info, IXs, facilities, contacts, peering policy | Optional API key | +| **RIPE Stat** | [stat.ripe.net](https://stat.ripe.net/) | BGP state, prefixes, visibility, neighbours, RPKI, abuse contacts | No | +| **RIPE Atlas** | [atlas.ripe.net](https://atlas.ripe.net/) | Probes, ping, traceroute, DNS measurements from global probes | No (API key for creating measurements) | +| **bgp.he.net** | [bgp.he.net](https://bgp.he.net/) | Peers, upstreams, downstreams, originated prefixes | No | +| **bgproutes.io** | [bgproutes.io](https://bgproutes.io/) | 3,294 vantage points, RIB entries, ROV + ASPA validation | API key | +| **IRR Explorer** | [irrexplorer.nlnog.net](https://irrexplorer.nlnog.net/) | BGP vs IRR origin consistency checks | No | +| **RIPE DB** | [rest.db.ripe.net](https://rest.db.ripe.net/) | Route objects, as-sets, aut-num, ASPA objects, WHOIS | No | +| **RPKI Validators** | Local Routinator / RIPE RPKI | ROA validation, VRP list, resource certificates | No | +| **MANRS Observatory** | [observatory.manrs.org](https://observatory.manrs.org/) | MANRS participation and conformance score | No | +| **CAIDA AS Rank** | [asrank.caida.org](https://asrank.caida.org/) | AS relationships, customer cones, rankings | No | +| **Spamhaus / Blocklists** | Via RIPE Stat | DROP list, blocklist presence checks | No | + +All data is fetched directly from these sources at query time (with caching). PeerCortex does not maintain its own copy of the global routing table or operate BGP collectors. --- -## Feature Comparison +## Self-Hosting Guide -How PeerCortex compares to existing tools: +PeerCortex is designed to run entirely on your own infrastructure. No cloud services required. -| Feature | PeerCortex | bgpq4 | peeringdb-py | ripestat-cli | bgpstream | -|---------|:----------:|:-----:|:------------:|:------------:|:---------:| -| ASN Lookup (unified) | Yes | - | Partial | Partial | - | -| Peering Discovery | AI-ranked | - | Basic | - | - | -| BGP Analysis | Yes | - | - | Yes | Yes | -| Anomaly Detection | AI-powered | - | - | Partial | Yes | -| RPKI Monitoring | Yes | - | - | Partial | - | -| Network Comparison | Yes | - | - | - | - | -| Report Generation | AI-powered | - | - | - | - | -| MCP Integration | Native | - | - | - | - | -| Local AI | Ollama | - | - | - | - | -| Multi-source | 6 sources | 1 (IRR) | 1 (PDB) | 1 (RIPE) | 1 (RIS) | -| Self-hosted | Yes | Yes | Yes | Yes | Yes | -| No cloud dependency | Yes | Yes | Yes | Yes | Yes | +### Prerequisites -PeerCortex is not a replacement for these excellent tools β€” it complements them by providing a unified, AI-enhanced interface for the most common network intelligence tasks. - ---- - -## Architecture - -``` -β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” -β”‚ MCP Client (Claude Code) β”‚ -β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ - β”‚ stdio / SSE -β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” -β”‚ PeerCortex MCP Server β”‚ -β”‚ β”‚ -β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β” β”‚ -β”‚ β”‚ lookup β”‚ β”‚ peering β”‚ β”‚ bgp β”‚ β”‚ rpki β”‚ β”‚compare β”‚ β”‚report β”‚ β”‚ -β”‚ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜ β””β”€β”€β”¬β”€β”€β”˜ β””β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”˜ β”‚ -β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ -β”‚ β”‚ β”‚ -β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”β”‚ -β”‚ β”‚ Source Aggregation Layer β”‚β”‚ -β”‚ β”‚ PeeringDB Β· RIPE Stat Β· bgp.he.net Β· Route Views Β· IRR Β· RPKI β”‚β”‚ -β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜β”‚ -β”‚ β”‚ -β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ -β”‚ β”‚ SQLite Cache β”‚ β”‚ Ollama (Local AI) β”‚ β”‚ -β”‚ β”‚ Response caching β”‚ β”‚ Analysis & report generation β”‚ β”‚ -β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ -β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ -``` - -For detailed architecture documentation, see [docs/architecture.md](docs/architecture.md). - ---- - -## Quick Start +- **Node.js 20+** (LTS recommended) +- **Ollama** installed and running locally (for MCP Server AI features) +- **Docker** (optional, for containerized deployment) ### Option 1: Docker (Recommended) ```bash # Clone the repository -git clone https://github.com/peercortex/peercortex.git -cd peercortex +git clone https://github.com/renefichtmueller/PeerCortex.git +cd PeerCortex # Copy environment configuration cp .env.example .env +# Edit .env with your settings (all have sensible defaults) # Start PeerCortex + Ollama docker compose up -d -# Pull the AI model +# Pull the AI model inside the Ollama container docker exec peercortex-ollama ollama pull llama3.1 # Verify it's running docker logs peercortex ``` +The Docker Compose setup includes: +- **PeerCortex server** (Node.js 22 Alpine, non-root user, persistent SQLite cache volume) +- **Ollama** (for local AI inference, optional GPU passthrough) +- **Routinator** (optional, uncomment in docker-compose.yml for local RPKI validation) + ### Option 2: Local Installation ```bash -# Prerequisites: Node.js 20+, Ollama installed +# Prerequisites: Node.js 20+, Ollama installed and running # Clone and install -git clone https://github.com/peercortex/peercortex.git -cd peercortex +git clone https://github.com/renefichtmueller/PeerCortex.git +cd PeerCortex npm install # Configure cp .env.example .env -# Edit .env with your settings -# Build and start +# Build TypeScript npm run build + +# Start the MCP server npm start ``` -### Option 3: npx (One-liner) +### Option 3: npx (One-Liner) ```bash -# Run directly without installing OLLAMA_BASE_URL=http://localhost:11434 npx peercortex ``` +### Running the Web Dashboard + +The web dashboard is served by `server.js` (a standalone Node.js HTTP server with no framework dependencies): + +```bash +node server.js +``` + +The server listens on port 3100 by default and serves both the dashboard (static HTML) and the API endpoints. + ### Configure Claude Code Add to your Claude Code MCP configuration (`~/.claude.json` or project `.claude.json`): @@ -673,7 +665,7 @@ Add to your Claude Code MCP configuration (`~/.claude.json` or project `.claude. "mcpServers": { "peercortex": { "command": "node", - "args": ["/path/to/peercortex/dist/mcp-server/index.js"], + "args": ["/path/to/PeerCortex/dist/mcp-server/index.js"], "env": { "OLLAMA_BASE_URL": "http://localhost:11434", "OLLAMA_MODEL": "llama3.1" @@ -696,13 +688,15 @@ All configuration is done via environment variables. Copy `.env.example` to `.en | `OLLAMA_BASE_URL` | `http://localhost:11434` | Ollama API endpoint | | `OLLAMA_MODEL` | `llama3.1` | LLM model for AI analysis | | `PEERINGDB_API_KEY` | _(empty)_ | Optional PeeringDB API key for higher rate limits | +| `BGPROUTES_API_KEY` | _(empty)_ | bgproutes.io API key for RIB queries and ASPA validation | +| `BGPROUTES_API_URL` | `https://api.bgproutes.io/v1` | bgproutes.io API endpoint | | `RIPE_STAT_SOURCE_APP` | `peercortex` | RIPE Stat source app identifier | | `ROUTINATOR_URL` | `http://localhost:8323` | Local RPKI validator URL | | `RIPE_RPKI_VALIDATOR_URL` | `https://rpki-validator.ripe.net/api/v1` | RIPE RPKI fallback | | `CACHE_DB_PATH` | `./peercortex-cache.db` | SQLite cache file location | -| `CACHE_TTL_SECONDS` | `3600` | Cache time-to-live (1 hour) | -| `MCP_TRANSPORT` | `stdio` | MCP transport: `stdio` or `sse` | -| `MCP_PORT` | `3100` | Port for SSE transport | +| `CACHE_TTL_SECONDS` | `3600` | Default cache TTL (1 hour) | +| `MCP_TRANSPORT` | `stdio` | MCP transport protocol: `stdio` or `sse` | +| `MCP_PORT` | `3100` | Port for SSE transport / web dashboard | | `LOG_LEVEL` | `info` | Log level: `debug`, `info`, `warn`, `error` | ### Recommended Ollama Models @@ -712,26 +706,111 @@ All configuration is done via environment variables. Copy `.env.example` to `.en | `llama3.1` | 8B | General analysis (recommended default) | | `llama3.1:70b` | 70B | Deep analysis (requires 40GB+ RAM) | | `mistral` | 7B | Fast analysis, good quality | -| `codellama` | 7B | Technical report generation | | `mixtral` | 8x7B | Complex multi-source analysis | +| `qwen2.5:14b` | 14B | Balanced speed and quality | + +### Optional: PeeringDB API Key + +PeerCortex works without a PeeringDB API key, but you'll hit rate limits faster with anonymous access (60 req/min). To get a free API key: + +1. Create an account at [peeringdb.com](https://www.peeringdb.com/) +2. Go to your profile settings +3. Generate an API key +4. Add it to your `.env` file + +### Optional: Local RPKI Validator + +For faster RPKI validation without depending on external services, run Routinator locally: + +```bash +# Via Docker +docker run -d --name routinator -p 8323:8323 nlnetlabs/routinator + +# Or uncomment the routinator service in docker-compose.yml +``` --- -## Privacy & Security +## Architecture -PeerCortex is designed for privacy-conscious network operators: +``` + User Query + | + +----------------+----------------+ + | | + Web Dashboard (browser) Claude Code (MCP client) + | | + | HTTP REST API MCP Protocol (stdio/SSE) + | | + +---------+---------------------------------+---------+ + | PeerCortex Server | + | | + | +--------+ +-------+ +-----+ +------+ +--------+ | + | | lookup | |peering| | bgp | | rpki | |compare | | + | +---+----+ +---+---+ +--+--+ +--+---+ +---+----+ | + | | | | | | | + | +---+----------+--------+-------+----------+---+ | + | | Source Aggregation Layer | | + | | | | + | | PeeringDB RIPE Stat bgp.he.net IRR RPKI | | + | | bgproutes.io RIPE Atlas MANRS Spamhaus | | + | +-----------------------------------------------+ | + | | + | +-------------------+ +------------------------+ | + | | In-Memory Cache | | Ollama (Local AI) | | + | | TTL-based, 500 | | Analysis & Reports | | + | | entry limit | | 100% local inference | | + | +-------------------+ +------------------------+ | + +------------------------------------------------------+ +``` + +### Component Details + +| Component | Location | Description | +|-----------|----------|-------------| +| MCP Server | `src/mcp-server/` | Model Context Protocol server with 25+ tools | +| Tool Handlers | `src/mcp-server/tools/` | Individual tool implementations with Zod schemas | +| Data Sources | `src/sources/` | Client modules for each external API | +| AI Layer | `src/ai/` | Ollama client with specialized prompt templates | +| Cache Layer | `src/cache/` | SQLite-backed cache with WAL mode | +| Type Definitions | `src/types/` | Shared TypeScript interfaces | +| Web Dashboard | `public/index.html` | Single-page application served by server.js | +| API Server | `server.js` | Standalone HTTP server for dashboard + REST API | + +### Data Flow + +1. User enters an ASN on the dashboard or sends an MCP tool invocation +2. Request is validated (input sanitization, rate limiting) +3. In-memory cache is checked for fresh data +4. External APIs are queried **in parallel** (PeeringDB + RIPE Stat + bgp.he.net + ...) +5. Results are merged, cached, and optionally analyzed by Ollama +6. Structured JSON response is returned + +For detailed architecture documentation, see [docs/architecture.md](docs/architecture.md). + +--- + +## Privacy and Security + +PeerCortex is built for privacy-conscious network operators who handle sensitive routing data: - **100% Local AI**: All inference runs on your machine via Ollama. No data is sent to OpenAI, Anthropic, Google, or any other cloud AI service. -- **No Telemetry**: PeerCortex does not collect or transmit any usage data. -- **No Account Required**: Works without any API keys (PeeringDB key is optional for higher rate limits). -- **Local Cache**: All cached data is stored in a local SQLite database on your machine. -- **Open Source**: Full source code available for audit. MIT license. +- **No Telemetry**: PeerCortex does not collect or transmit any usage data. There are no analytics, tracking pixels, or phone-home mechanisms. +- **No Account Required**: The dashboard and MCP server work without any API keys. PeeringDB and bgproutes.io keys are optional for higher rate limits and additional features. +- **Local Cache**: All cached data is stored in local memory (dashboard) or local SQLite (MCP server). No external database dependencies. +- **Open Source**: Full source code available for audit under the MIT license. +- **Rate Limiting**: Built-in rate limiting (60 req/min per IP) protects against abuse when self-hosting. +- **Non-Root Container**: The Docker image runs as a non-root user (`peercortex:1001`). -**Data flow:** -1. Your query goes from Claude Code to the local PeerCortex MCP server -2. PeerCortex queries public APIs (PeeringDB, RIPE Stat, etc.) for factual data -3. Ollama (running locally) analyzes the data -4. Results are returned to Claude Code +**Data flow summary:** + +``` +Your Browser/Claude Code + --> PeerCortex (your machine) + --> Public APIs (PeeringDB, RIPE Stat, etc.) for factual network data + --> Ollama (your machine) for AI analysis + <-- Results returned to you +``` At no point does your query content, network topology, or analysis results leave your machine for AI processing. @@ -741,20 +820,18 @@ At no point does your query content, network topology, or analysis results leave ### What is ASPA? -**Autonomous System Provider Authorization (ASPA)** is an RPKI-based mechanism defined in [RFC 9582](https://www.rfc-editor.org/rfc/rfc9582) that enables detection and prevention of route leaks. While RPKI ROA (Route Origin Authorization) validates who is authorized to **originate** a prefix, ASPA validates the **path** a route takes through the Internet. +**Autonomous System Provider Authorization (ASPA)** is an RPKI-based mechanism defined in [RFC 9582](https://www.rfc-editor.org/rfc/rfc9582) that enables detection and prevention of route leaks. While RPKI ROA validates who is authorized to **originate** a prefix, ASPA validates the **path** a route takes through the Internet. -Each AS publishes an ASPA object declaring its authorized upstream providers. When a BGP router receives a route, it can walk the AS path and verify that each customer-to-provider hop is authorized. Unauthorized hops indicate a route leak β€” a common and damaging class of BGP incidents. +Each AS publishes an ASPA object declaring its authorized upstream providers. BGP routers can walk the AS path and verify that each customer-to-provider hop is authorized. Unauthorized hops indicate a route leak. -**Why it matters:** +**Why ASPA matters:** -- Route leaks caused by misconfigured BGP sessions are responsible for major Internet outages every year +- Route leaks from misconfigured BGP sessions cause major Internet outages every year - ASPA provides cryptographic proof of provider relationships, complementing ROA validation -- Together, ROA + ASPA cover the two most important BGP security gaps: origin validation and path validation -- ASPA is particularly effective against lateral ISS-ISS leaks and customer-to-provider leaks (RFC 7908) +- Together, ROA + ASPA address the two most critical BGP security gaps: origin validation and path validation +- ASPA is effective against lateral ISS-ISS leaks and customer-to-provider leaks (RFC 7908) -### ASPA Tools - -PeerCortex provides 6 ASPA-focused tools: +### ASPA Tools in PeerCortex | Tool | Description | |------|-------------| @@ -765,235 +842,222 @@ PeerCortex provides 6 ASPA-focused tools: | `peercortex_aspa_coverage` | ASPA adoption statistics per IXP or geographic region | | `peercortex_aspa_leaks` | Real-time route leak detection using ASPA validation | -### Example Conversations +### ASPA Example Workflows -**Analyze ASPA readiness:** +**Check ASPA readiness:** ``` -You: Analyze ASPA readiness for AS13335 -Claude: AS13335 (Cloudflare) currently has no registered ASPA object. Based on BGP path - analysis, the detected upstream providers are AS174 (Cogent) and AS3356 (Lumen). - Recommendation: Register an ASPA object listing these providers via the RIPE DB. +You: Analyze ASPA readiness for AS199121 + +PeerCortex: AS199121 currently has no registered ASPA object. + Detected upstream providers from BGP path analysis: + - AS174 (Cogent Communications) + - AS3356 (Lumen Technologies) + Recommendation: Register an ASPA object listing these providers. ``` **Generate an ASPA object:** ``` -You: Generate an ASPA object for AS13335 -Claude: Here is a RIPE DB-ready ASPA template for AS13335: +You: Generate an ASPA object for AS199121 - aut-num: AS13335 - upstream: AS174 # Cogent (confidence: 95%) - upstream: AS3356 # Lumen (confidence: 90%) - mnt-by: MNT-CLOUDFLARE - source: RIPE - - Submit at: https://apps.db.ripe.net/db-web-ui/webupdates +PeerCortex: RIPE DB-ready ASPA template: + aut-num: AS199121 + upstream: AS174 # Cogent (confidence: 95%) + upstream: AS3356 # Lumen (confidence: 90%) + mnt-by: MNT-YOUR-MAINTAINER + source: RIPE ``` -**What-if simulation:** +**ASPA simulation:** ``` You: What would ASPA have prevented in the last 30 days? -Claude: Analyzing 15 BGP incidents from the last 30 days... - ASPA would have prevented 11 of 15 incidents (73% prevention rate). - - Route leaks: 8/10 prevented - - Hijacks: 2/3 prevented - - Misconfigurations: 1/2 prevented + +PeerCortex: Analyzed 15 BGP incidents from the last 30 days. + ASPA would have prevented 11 of 15 incidents (73% prevention rate). + Route leaks: 8/10 prevented + Hijacks: 2/3 prevented + Misconfigurations: 1/2 prevented ``` -**IXP adoption:** -``` -You: Show ASPA adoption at DE-CIX Frankfurt -Claude: DE-CIX Frankfurt ASPA Coverage: - - Total participants: 950 - - With ASPA objects: 85 (8.9%) - - Top adopters: AS13335 (Cloudflare), AS32934 (Meta), AS15169 (Google) -``` +--- -**Leak detection:** -``` -You: Detect route leaks using ASPA for 1.1.1.0/24 -Claude: Analyzing last 24 hours of BGP updates for 1.1.1.0/24... - Found 3 route leak events: - - CRITICAL: AS64501 leaked 1.1.1.0/24 to AS3356 (17:42 UTC) - - HIGH: AS64502 re-originated 1.1.1.0/24 (03:15 UTC) - - MEDIUM: AS64503 lateral leak to AS6939 (21:08 UTC) -``` +## Feature Comparison -**Deployment simulation:** -``` -You: Simulate: what if all DE-CIX members deployed ASPA? -Claude: If all 950 DE-CIX Frankfurt members deployed ASPA: - - Route leak prevention rate would increase from 8.9% to ~92% - - An estimated 340 route leak incidents per year would be prevented - - Critical incidents (affecting /8 or larger) would drop by 95% -``` +How PeerCortex compares to existing network intelligence tools: + +| Feature | PeerCortex | bgpq4 | peeringdb-py | ripestat-cli | bgpstream | +|---------|:----------:|:-----:|:------------:|:------------:|:---------:| +| Unified ASN Lookup | Yes | - | Partial | Partial | - | +| Web Dashboard | Yes | - | - | - | - | +| Peering Discovery | AI-ranked | - | Basic | - | - | +| BGP Analysis | Yes | - | - | Yes | Yes | +| RPKI Monitoring | Yes | - | - | Partial | - | +| ASPA Verification | Yes | - | - | - | - | +| Network Health Score | Yes (13 checks) | - | - | - | - | +| Network Comparison | Yes | - | - | - | - | +| Report Generation | AI-powered | - | - | - | - | +| MCP Integration | Native | - | - | - | - | +| Local AI | Ollama | - | - | - | - | +| Multi-source | 10+ sources | 1 (IRR) | 1 (PDB) | 1 (RIPE) | 1 (RIS) | +| Self-hosted | Yes | Yes | Yes | Yes | Yes | +| bgproutes.io integration | Yes | - | - | - | - | +| RIPE Atlas integration | Yes | - | - | - | - | + +PeerCortex complements these tools by providing a unified, AI-enhanced interface for the most common network intelligence tasks. --- ## Roadmap -### v0.1 β€” Foundation (Current) -- [x] Project structure and type definitions -- [x] MCP server with 6 tool definitions -- [x] PeeringDB API client -- [x] RIPE Stat API client -- [x] bgp.he.net scraper skeleton -- [x] Route Views / RIPE RIS client -- [x] IRR / WHOIS client -- [x] RPKI validator client -- [x] Ollama AI integration -- [x] SQLite cache layer -- [ ] Complete tool implementations -- [ ] Unit and integration tests +Planned features and improvements: -### v0.2 β€” Core Features -- [ ] Full ASN lookup with all sources -- [ ] Peering partner scoring algorithm -- [ ] BGP anomaly detection engine -- [ ] RPKI compliance reporting -- [ ] Network comparison logic -- [ ] Report templates (Markdown, JSON) - -### v0.3 β€” Intelligence -- [ ] AI-powered anomaly classification -- [ ] Peering request email generation -- [ ] Historical trend analysis -- [ ] Route leak correlation -- [ ] RPKI deployment tracking over time - -### v0.4 β€” Production -- [ ] SSE transport support -- [ ] Webhook alerts for anomalies -- [ ] Prometheus metrics endpoint -- [ ] Comprehensive test suite (80%+ coverage) -- [ ] Performance optimization -- [ ] npm package publishing - -### Future -- [x] bgproutes.io integration (ASPA validation support) -- [ ] BGP community analysis -- [ ] Traffic estimation from prefix visibility -- [ ] Peering ROI calculator -- [ ] Multi-language report generation -- [ ] Web dashboard (optional) -- [ ] Slack/Discord bot integration -- [ ] PeeringDB write API (submit peering requests) +- [ ] **BGP Alerting**: Real-time alerts for route leaks, hijacks, and anomalies via webhook/email +- [ ] **Historical Analysis**: Time-series tracking of RPKI coverage, prefix counts, and health scores +- [ ] **Batch ASN Analysis**: Analyze multiple ASNs in a single query for portfolio monitoring +- [ ] **PDF Report Export**: Generate downloadable PDF reports for management presentations +- [ ] **Grafana Dashboard**: Pre-built Grafana dashboards for continuous monitoring +- [ ] **RPKI ROA Diff**: Track ROA changes over time and alert on unexpected modifications +- [ ] **Peering Request Automation**: Auto-generate and send peering request emails +- [ ] **IX Route Server Analysis**: Evaluate route server filtering policies at each IXP +- [ ] **ASPA Adoption Tracker**: Track global ASPA deployment statistics over time +- [ ] **npm Package Publishing**: Publish MCP server as an npm package for one-line installation --- ## Contributing -Contributions are welcome! PeerCortex is built by network engineers, for network engineers. +Contributions are welcome. PeerCortex is built with TypeScript and follows standard Node.js conventions. -### Getting Started +### Development Setup ```bash -# Fork and clone -git clone https://github.com/YOUR_USERNAME/peercortex.git -cd peercortex +# Clone the repository +git clone https://github.com/renefichtmueller/PeerCortex.git +cd PeerCortex # Install dependencies npm install -# Run in development mode (auto-reload) +# Run in development mode (hot reload) npm run dev # Run tests npm test +# Run tests with coverage +npm run test:coverage + # Type checking npm run typecheck -# Linting +# Lint npm run lint +npm run lint:fix + +# Build +npm run build ``` -### Contribution Guidelines +### Project Structure -1. **Fork** the repository -2. **Create** a feature branch (`git checkout -b feat/amazing-feature`) -3. **Write tests** for your changes -4. **Ensure** all tests pass and types check -5. **Commit** using conventional commits (`feat:`, `fix:`, `docs:`, etc.) -6. **Push** your branch and open a Pull Request +``` +PeerCortex/ + src/ + mcp-server/ + index.ts # MCP server entry point + tools/ # Tool implementations + sources/ + peeringdb.ts # PeeringDB API client + ripe-stat.ts # RIPE Stat API client + bgp-he.ts # bgp.he.net HTML scraper + route-views.ts # Route Views (via RIPE Stat) + irr.ts # IRR/RIPE DB client + rpki.ts # RPKI validator client + ai/ # Ollama integration and prompts + cache/ # SQLite cache with WAL mode + types/ # TypeScript type definitions + public/ + index.html # Web dashboard (single page) + server.js # HTTP server for dashboard + REST API + docs/ + architecture.md # Detailed architecture documentation + data-sources.md # Data source reference + setup.md # Setup guide + screenshots/ # Dashboard screenshots + assets/ # Logo and demo assets + Dockerfile # Multi-stage Docker build + docker-compose.yml # Docker Compose with Ollama + tsconfig.json # TypeScript configuration +``` -### Areas Where Help is Needed +### Guidelines -- **bgp.he.net scraper**: Improve HTML parsing for all data tabs -- **Anomaly detection**: Implement route leak and hijack detection algorithms -- **RPKI compliance**: Complete the compliance reporting logic -- **Test coverage**: Unit and integration tests for all modules -- **Documentation**: Examples, tutorials, and API documentation -- **Performance**: Optimize parallel data source queries +- **TypeScript**: Strict mode enabled. All code must pass `npm run typecheck`. +- **Testing**: Write tests for new features. Target 80%+ coverage. +- **Linting**: Run `npm run lint:fix` before committing. +- **Data sources**: When adding a new data source, implement it as a module in `src/sources/` with a consistent client interface. +- **MCP tools**: New tools go in `src/mcp-server/tools/` with Zod input validation schemas. +- **No cloud dependencies**: PeerCortex must always work fully offline (except for querying public network data APIs). --- ## FAQ -**Q: Do I need an Ollama instance to use PeerCortex?** -A: Ollama is recommended for AI-powered features (analysis, ranking, report generation) but not strictly required. The data lookup tools (lookup, bgp, rpki) work without AI β€” they return raw structured data that Claude Code can interpret directly. +**Q: Does PeerCortex require an internet connection?** +A: Yes, for querying public network data APIs (PeeringDB, RIPE Stat, etc.). However, all AI processing runs locally via Ollama. Cached data is served from local storage when available. -**Q: Which Ollama model should I use?** -A: `llama3.1` (8B) is the recommended default. It provides excellent analysis quality while running on most hardware. For deeper analysis, try `llama3.1:70b` if you have 40GB+ RAM. +**Q: Can I use PeerCortex without Ollama?** +A: Yes. The web dashboard and all API endpoints work without Ollama. Ollama is only needed for the AI-powered features in the MCP server (peering partner ranking, report generation, anomaly analysis). -**Q: Does PeerCortex send my data to the cloud?** -A: No. All AI inference runs locally via Ollama. PeerCortex queries public APIs (PeeringDB, RIPE Stat, etc.) for factual network data, but your queries and analysis results never leave your machine. +**Q: Is there a hosted version?** +A: The live demo at [peercortex.org](https://peercortex.org) provides the web dashboard. For the full MCP server experience with AI features, self-host PeerCortex on your own infrastructure. -**Q: Can I use this without Claude Code?** -A: Yes! PeerCortex is a standard MCP server. It works with any MCP-compatible client, including Claude Desktop, custom MCP clients, or direct stdio interaction. +**Q: How often is the data refreshed?** +A: Data is fetched in real-time from upstream APIs at query time. Responses are cached locally for 5-10 minutes (configurable) to reduce API load and improve response times. -**Q: How accurate is the BGP anomaly detection?** -A: PeerCortex uses data from RIPE RIS collectors and Route Views, which are the same data sources used by academic BGP monitoring systems. AI analysis adds context but all findings are based on real routing data. +**Q: Can I use PeerCortex with Claude Desktop instead of Claude Code?** +A: Yes. PeerCortex is a standard MCP server that works with any MCP-compatible client, including Claude Desktop, Claude Code, or custom MCP clients. -**Q: Can I use this for production monitoring?** -A: PeerCortex v0.x is designed for interactive querying and analysis. Production monitoring with alerting is planned for v0.4+. For now, it complements (not replaces) production monitoring tools like BGPalerter. +**Q: Does PeerCortex support IPv6?** +A: Yes. All modules handle both IPv4 and IPv6 prefixes, addresses, and peering sessions. -**Q: What about IPv6?** -A: Full IPv6 support. All tools handle both IPv4 and IPv6 prefixes, and PeeringDB data includes IPv6 IX addresses. +**Q: What about private ASNs?** +A: PeerCortex queries public data sources. Private ASNs (64512-65534 and 4200000000-4294967294) will return limited results since they are not visible in the global routing table. -**Q: How do I get a PeeringDB API key?** -A: Create an account at [peeringdb.com](https://www.peeringdb.com/), go to your profile settings, and generate an API key. It's free and gives you higher rate limits. - -**Q: Can I run PeerCortex behind a firewall?** -A: Yes, with some considerations. PeerCortex needs outbound HTTP access to PeeringDB, RIPE Stat, bgp.he.net, and optionally RIPE RPKI. If you run Routinator locally, RPKI validation works fully offline. Ollama runs entirely local. +**Q: Can I run PeerCortex behind a reverse proxy?** +A: Yes. PeerCortex is a standard HTTP server that works behind nginx, Caddy, Traefik, or any other reverse proxy. Set appropriate `X-Forwarded-For` headers for accurate rate limiting. --- ## Acknowledgments -PeerCortex is built on the shoulders of these incredible projects and organizations: +PeerCortex builds on data from these organizations and projects: -- **[PeeringDB](https://www.peeringdb.com/)** β€” The freely available, user-maintained database of networks. Thank you to PeeringDB Inc. and all contributors who keep peering data open and accessible. -- **[RIPE NCC](https://www.ripe.net/)** β€” For RIPE Stat, RIPE RIS, and the RIPE Database. Essential infrastructure for Internet measurement and analysis. -- **[Route Views](https://www.routeviews.org/)** β€” University of Oregon's Route Views project for global routing table collection. -- **[Ollama](https://ollama.com/)** β€” Making local AI accessible and easy to run. -- **[NLnet Labs](https://nlnetlabs.nl/)** β€” For Routinator and advancing RPKI deployment. -- **[Hurricane Electric](https://he.net/)** β€” For bgp.he.net, an invaluable BGP toolkit. -- **[Model Context Protocol](https://modelcontextprotocol.io/)** β€” Anthropic's MCP specification enabling AI tool integration. +- **[PeeringDB](https://www.peeringdb.com/)** β€” The freely available, user-maintained database of networks, IXPs, and facilities +- **[RIPE NCC](https://www.ripe.net/)** β€” RIPE Stat API, RIPE Atlas, RIPE DB, and RPKI infrastructure +- **[Hurricane Electric](https://bgp.he.net/)** β€” BGP Toolkit for peer and prefix data +- **[bgproutes.io](https://bgproutes.io/)** β€” BGP monitoring with 3,294 vantage points worldwide +- **[NLnet Labs](https://nlnetlabs.nl/)** β€” Routinator RPKI validator +- **[NLNOG](https://nlnog.net/)** β€” IRR Explorer for BGP-IRR consistency checking +- **[MANRS](https://www.manrs.org/)** β€” Mutually Agreed Norms for Routing Security observatory +- **[CAIDA](https://www.caida.org/)** β€” AS relationship inference and ranking data +- **[Ollama](https://ollama.com/)** β€” Local LLM inference engine +- **[Model Context Protocol](https://modelcontextprotocol.io/)** β€” AI tool integration standard by Anthropic --- -## Ecosystem +## License -### Part of the Cortex Family - -PeerCortex is part of a growing ecosystem of AI-powered MCP tools: - -| Project | Description | -|---------|-------------| -| **[PaperCortex](https://github.com/papercortex/papercortex)** | AI-powered academic paper management and research assistant | -| **PeerCortex** | AI-powered network intelligence platform (you are here) | - -Each Cortex project follows the same philosophy: **local AI, open source, privacy-first, MCP-native**. +MIT License. See [LICENSE](LICENSE) for details. ---

- PeerCortex β€” Network intelligence, unified.
- Built with care for the network engineering community. + PeerCortex β€” Network intelligence for operators who demand answers, not tab switching.

- +

+ Live Demo · + GitHub · + Get Started · + Architecture +

diff --git a/docs/screenshots/01-dashboard-overview.png b/docs/screenshots/01-dashboard-overview.png new file mode 100644 index 0000000..6abe3d9 Binary files /dev/null and b/docs/screenshots/01-dashboard-overview.png differ diff --git a/docs/screenshots/02-health-report.png b/docs/screenshots/02-health-report.png new file mode 100644 index 0000000..7d2a673 Binary files /dev/null and b/docs/screenshots/02-health-report.png differ diff --git a/docs/screenshots/03-aspa-status.png b/docs/screenshots/03-aspa-status.png new file mode 100644 index 0000000..8fe8ac8 Binary files /dev/null and b/docs/screenshots/03-aspa-status.png differ diff --git a/docs/screenshots/04-aspa-deep-analysis.png b/docs/screenshots/04-aspa-deep-analysis.png new file mode 100644 index 0000000..17d1c2e Binary files /dev/null and b/docs/screenshots/04-aspa-deep-analysis.png differ diff --git a/docs/screenshots/05-routing-overview.png b/docs/screenshots/05-routing-overview.png new file mode 100644 index 0000000..314e7ab Binary files /dev/null and b/docs/screenshots/05-routing-overview.png differ