Discovery and reconciliation

When a gateway-enabled node is collected, rConfig discovers the elements behind it and keeps their device records in step with what the gateway reports. You do not maintain the list by hand.

---

What runs, and when

Discovery happens at the end of every gateway collection, gated by the tl1Gateway flag on the template (setup):

1. rConfig collects the gateway’s own configuration over its session.
2. On the same session it runs the platform’s neighbour command and reads the element TIDs out of the reply.
3. It reconciles those TIDs against the element devices already known, across every gateway.

Which command runs, and how its records are shaped, comes from tl1Vendor:

Platform	Neighbour command
Ciena 6500	RTRV-NE-LIST
Infinera DTN-X	RTRV-TIDMAP
Cisco ONS 15454	RTRV-MAP-NETWORK

To trigger it, collect the gateway: open the device and click Download Now, or let its scheduled task run.

Note

Discovery is idempotent. Running it again on an unchanged gateway adds nothing and changes nothing, so collecting a gateway on a schedule keeps its element set current at no extra cost.

Caution

If rConfig cannot read the reply as that platform’s format, it reports the run as inconclusive and leaves the known elements alone. It does not treat an unreadable answer as “this gateway has no elements”, because that would flag every element behind it as missing. An unreadable reply almost always means tl1Vendor names the wrong platform; check the activity log.

---

Reconciliation states

Each element carries a discovery state, shown in the TL1 Gateway panel on both the gateway and the element:

State	Meaning
discovered	The gateway reported this element on the last discovery.
missing	The element was present before but the gateway no longer reports it (removed, renamed, or unreachable). The device and its history are kept, not deleted.
manual	The element device was created by an operator rather than by discovery.

A missing element flips back to discovered automatically the next time the gateway reports it again.

For a dual-homed element, this state is per path. If one gateway stops reporting it while another still does, that path is marked missing and the element itself stays discovered, because it is still reachable. It is only marked missing once every path to it has gone. Losing the primary path promotes a surviving one, so collection continues without you doing anything.

Caution

Elements are never deleted by reconciliation. A node that drops out of the neighbour list is flagged missing so its configuration history is preserved. Removing it is a deliberate operator action.

Discovered elements on a gateway, with one flagged missing

---

New elements are collected automatically

When discovery finds an element for the first time, rConfig creates the device and queues a first collection for it straight away, routed through the gateway. Re-running discovery does not re-collect elements it already knows, so a gateway with a large fleet is not re-pulled on every run. After the first pull, each element follows its own schedule like any other device.

Where the platform reports an element’s own management address or model, rConfig stores those on the device record. Only Cisco reports a model per element, and only Ciena and Cisco report an address, so Infinera elements show their gateway’s address as a placeholder.

An element that is already known is never created twice. When a second gateway reports a TID rConfig has already seen, the element gains a path through that gateway and nothing else changes: no duplicate device, no second collection queued. Discovery order does not matter, so whichever gateway you collect first creates the device and the others attach to it.

A standalone gateway, one whose neighbour command returns an empty list, simply creates no elements. Discovery still runs; it just finds nothing.

---

Next step: Collect the elements.