Data flow

This page describes what happens — from your point of view — when the network moves. Skim the Architecture overview and the Glossary first; this page assumes you know what a peer, a domain, and a topology change are.

The pipeline at a glance

Every BGP-LS peer pushes UPDATEs. Prelude TE consolidates them into a single per-domain view and reflects every change in three places at once — the web UI, the REST API, and every connected NATS output.

What you see in the UI

The built-in UI on port 4040 updates live, no refresh needed.

When a session comes up, the peer detail page shows its state walking through idle → connect → active → opensent → openconfirm → established, with the message and update counters ticking as BGP-LS data flows in. The state-history table records every transition with its timestamp and, on failure, the reason returned by the BGP stack.

When the network itself moves, the topology view picks up new nodes, links, and prefixes as soon as the engine processes the corresponding NLRI. Flex-Algo views refresh on the same cadence.

If a session drops, the peer state moves out of established and back through the state machine. Entities that were reported exclusively by that peer disappear from the graph; everything reported by at least one other peer stays in place. The session reconnects on its own according to the configured connect-retry timer.

What you read from the API

The REST API exposes the same view in a form you can script against — peers and their state, the list of domains, and the contents of each domain graph. See the API reference for the full surface.

Two properties to keep in mind when querying the API:

• The topology is live, not stored. It is rebuilt from your peers on every restart. Right after a restart you will see the graph re-populate as peers come up and re-walk their LSDB; expect a few seconds before it stabilizes.
• You can query one domain or all of them. The API lets you scope a request to a single domain when you only care about one IGP, or ask for the merged view across every domain when your network spans several connected IGP scopes.

What you receive on NATS

Every topology change — added, updated, or withdrawn entity — is published to your configured NATS outputs, one message per change. All enabled outputs receive every message in parallel.

Two guarantees the stream gives you:

• Withdrawals are always published. If an entity leaves the graph, your subscriber learns about it.
• Updates are deduplicated. Networks re-announce unchanged state all the time (refresh cycles, periodic re-advertisements). You only get a message when the payload differs from the previous one for that entity. This is why you can subscribe to a high-volume collector and still see a quiet stream.

For the topic format and on-the-wire payload shape, see Outputs / NATS.

What you control where

A short reference for "where does this knob live":

• Which routers to peer with — Peer records.
• How to authenticate the session — auth_type and auth_password on the peer.
• Session pacing — hold_time, keepalive_time, and connect_retry on the peer.
• Where the data goes downstream — Output records (NATS for now).
• Whether outputs use TLS / what CA to trust — use_tls and ca_cert_path on the output.

Every one of these is editable at runtime through the API or the UI; the engine reconciles its sessions and connections without a restart.

Next

You now know what the engine produces. The fastest way to lock in the model is to actually run the pipeline — head to Installation, then to First peer.