Change events

Whenever the consolidated topology moves — a node appears, a link metric changes, a prefix is withdrawn — Prelude TE emits a change event. There are two places those events show up: the Topology page in the web UI, which renders them live, and your configured NATS outputs, which receive a message per change for downstream consumers.

What counts as a change

Three kinds of change can happen to any entity in the graph:

• Added — the entity was not in the graph before. A new node has appeared, a new link has come up, a new prefix has been advertised.
• Updated — the entity already existed and one or more of its attributes changed. A link metric moved, a node started advertising a new locator, a prefix gained a new Prefix SID.
• Withdrawn — the entity left the graph. The last peer that was reporting it has stopped — either because the BGP-LS NLRI was withdrawn or because the source peer itself went away. See BGP Peers / Peer redundancy for how multi-source attribution decides when a withdraw actually happens.

Every change is tagged with the domain it belongs to, the entity type (node, link, or prefix), and a timestamp.

What you see in the UI

The Topology page is wired to a live event stream. When the network moves, the affected entity highlights briefly and its side-panel attributes update without a refresh. Withdrawn entities disappear from the rendering, and counters at the top of the page update to reflect the new totals.

What you receive on NATS

If you have configured a NATS output, every change is also published to your message bus, one message per change. Subscribers receive the full exported view of the entity for adds and updates, or a withdrawal marker for withdraws.

The payload is the same structured JSON object you see in the Topology view and read from the REST API — never a raw BGP-LS NLRI. Consumers can read it directly without parsing BGP.

Two properties of the NATS stream are worth knowing:

• 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, so subscribers see a quiet stream even on a busy collector.

For the topic format, the exact payload schema, and how to wire a NATS consumer, see Outputs / NATS.

When a peer disappears

A few notes specific to peers leaving the engine — disabled, deleted, or stuck in a non-established state:

• Entities reported by at least one other peer stay in the graph. Only their source-peers list shortens; no withdraw event is emitted for them.
• Entities reported only by the departing peer are withdrawn from the graph and a withdraw event is published for each one.

That is what makes redundant peers safe to add and to remove.