Skip to content
Documentation Prelude Topology Engine 1.0.0

Peer redundancy

Why and how to peer Prelude TE with more than one BGP-LS speaker, how consolidation handles duplicates, and what happens when a peer goes away.

A single BGP-LS peer is a single point of failure for your topology visibility. If that peer drops, the engine eventually withdraws every node, link, and prefix it was uniquely reporting — even if your actual network is still up.

In most production networks, the natural source for BGP-LS is a pair of route reflectors: they already concentrate the link-state view of an IGP and hand it out over BGP, which makes them the natural feed for a BGP-LS collector.

Recommendation

For any deployment beyond a small evaluation:

  • Peer with at least two BGP-LS speakers per IGP scope, usually the same pair of route reflectors your control plane already relies on.
  • Add one direct router session as a sanity check, so a reflector outage unrelated to the routers themselves does not silence the topology view.

This pairs naturally with how Prelude TE consolidates duplicates: every node, link, and prefix tracks its source peers. Losing one peer only drops the entities unique to it; everything else stays in place.

How consolidation handles duplicates

When two peers advertise the same node, link, or prefix — which is normal with redundant reflectors — Prelude TE tracks the source peer on every entity. The graph holds one copy of the entity with the list of peers reporting it, not two copies.

Use the same BGP-LS instance ID on every peer for a given IGP

Prelude TE keys each domain on the BGP-LS Instance Identifier advertised in the Node NLRI. If two peers export the same IGP scope with different instance IDs, the engine treats them as two separate domains and consolidation does not happen. Configure the same instance ID on every router or route reflector that exports the same IGP.

Designing for it

A few rules of thumb when adding peers:

  • Match the redundancy that already exists. If your network has a primary and a standby reflector, peer with both.
  • Pin every peer in the same IGP scope to the same BGP-LS instance ID (see the callout above).
  • Stay under the license cap. Every peer record counts against the cap, enabled or not — including the redundant ones. See Getting Started / Licensing.

A typical production deployment for one IGP scope looks like this:

  • Two route reflectors as primary BGP-LS sources, paired the same way they are paired for service routes.
  • One direct session to a chosen router in the same scope, used as a sanity check — if the reflectors fall silent for a reason unrelated to the routers themselves, the direct session keeps the topology populated.

Scale the pattern by adding more reflectors as your network grows, or by repeating it once per IGP scope when you maintain multiple domains side by side.

What happens during an outage

  • A peer that drops below established stops contributing new updates immediately. Existing entities stay in place as long as another peer is still reporting them.
  • Once the session has been down long enough for the engine to consider its data stale, entities reported only by that peer are withdrawn from the graph — and withdraw events flow out on NATS as usual.
  • When the peer comes back, the entities re-appear on the next pass through its LSDB. Subscribers see update events that resemble fresh additions.

This is why two peers — even with overlapping data — are enough to keep the topology stable during a routine route-reflector failover.

Filtering by: