as path topology

Pre-Alpha. This page describes behavior that may change. Not for production use.

Use the Looking Glass topology graph to visualise a real network's AS paths. The Looking Glass renders a directed acyclic graph of AS paths for any prefix, server-side in pure Go, with the result embedded as inline SVG. This blueprint covers how to turn that into a useful operator tool for investigating routing anomalies, visualising peering relationships, and explaining BGP to people who do not already know what an AS path is.

What the graph shows

The AS path topology graph at /lg/graph?prefix=X takes every path the local RIB knows for the prefix X and renders them as a layered graph.

• Each node is an AS number, with the organisation name from Team Cymru DNS when the decorator is available.
• Each edge represents a peering link between two ASes.
• The layout is left-to-right: source ASes on the left, the origin AS on the right.
• Consecutive duplicate ASNs (AS prepending) collapse to a single node, so the graph stays readable.
• Multiple paths to the same prefix render as branches in the DAG.
• Graphs are capped at 100 nodes to prevent resource exhaustion from pathological inputs.

The rendering is entirely server-side. No JavaScript graph library, no GraphViz invocation, no WASM. The SVG is generated in Go with a Sugiyama-inspired layout algorithm and returned as a fragment that the browser drops into the page.

Deploy the Looking Glass

The topology graph is part of the Looking Glass, so the first step is the same as the public Looking Glass blueprint.

environment {
    looking-glass {
        enabled true;
        server main {
            ip   127.0.0.1;
            port 8443;
        }
    }
}

Bind to 127.0.0.1 for an internal-only tool. The topology graph is cheap to render but it is not rate-limited, so a public deployment should either sit behind a reverse proxy with rate limiting or bind to a trusted interface.

Using the graph

Open http://localhost:8443/lg/lookup in a browser. Type a prefix or an IP in the search box. The page does a prefix lookup, shows the paths in the list view, and renders the topology graph below the list.

For script or API access, the endpoint is:

curl -s 'http://localhost:8443/lg/graph?prefix=8.8.8.8/32'

The response is an SVG fragment suitable for embedding directly in another page or rendering with an SVG viewer.

Three operator use cases

Explaining a routing anomaly. When a customer asks "why does traffic to prefix X go via transit A instead of transit B", the topology graph makes the answer visible. Open the graph, point at the paths, and explain that the best path runs through transit A because of LOCAL_PREF (or AS-path length, or whatever the actual reason is).

Visualising peering relationships. The graph for a popular prefix (for example, Google Public DNS) shows the AS paths you have for it, which is a good proxy for how your upstream peering is structured. If you peer directly with a major network, you can see it in the graph.

Finding unexpected transits. If a prefix you expected to see via a specific peer is actually coming via a different upstream, the graph shows it. This is the fastest way to catch leaks, mis-announcements, and accidentally-preferred routes.

Embedding the graph elsewhere

The graph is a fragment, so you can embed it in your own tooling.

<div id="topology">
  <object data="https://lg.example.com/lg/graph?prefix=8.8.8.8/32"
          type="image/svg+xml">
  </object>
</div>

Or pull it into a server-rendered page:

import requests

svg = requests.get("http://localhost:8443/lg/graph",
                   params={"prefix": "8.8.8.8/32"}).text

The SVG is self-contained (no external CSS, no external fonts) so it renders correctly in isolation.

What could go wrong

Empty graph. If the prefix is not in your RIB, the graph is empty. Check that the prefix actually has a path in your table:

ze cli -c "rib routes received | match 8.8.8.8"

If there is no route, there is no graph. Add the upstream that carries it, or look for a more popular prefix first.

Graph cut off at 100 nodes. A pathological prefix with unusual AS-path structure can hit the 100-node cap. The graph shows the truncated version. There is no way to raise the cap from config today; the limit is a safety bound against resource exhaustion.

Slow ASN name decoration. The topology graph looks up organisation names via Team Cymru DNS. Every ASN in the graph is one DNS lookup the first time it appears. If your DNS resolver is cold or slow, the first render is slow. Subsequent renders use the cache. See system configuration for the DNS tuning.

Public exposure. The topology graph is the same read-only Looking Glass surface as the rest of /lg/. Exposing it publicly is fine (it shows no more than the rest of the Looking Glass) but it should still sit behind the same rate limiting as everything else in the Looking Glass.

See also

• Looking Glass for the full interface reference.
• Public Looking Glass blueprint for deployment.
• In-tree Looking Glass graph source for the rendering code.