Collection Methods guides

rConfig can get a configuration off a device in several ways: an interactive CLI session, TL1 for optical nodes, a script you supply, REST API calls, or a file the device uploads itself, with SNMP traps deciding when a backup runs. These guides compare those methods, explain what each one changes about how a device is managed, and help you choose. The step-by-step procedures stay in the main docs, starting at Configuration Backups; these pages explain the trade-offs behind them.

Pull, push and trigger

The methods differ first in who starts the transfer.

Pull. rConfig opens a session to the device and asks for the configuration. CLI, TL1, scripts and API collections all work this way.
Push. The device sends a file to rConfig over TFTP, FTP or SFTP, and rConfig files it against the right device. This is xFTP.
Trigger. An SNMP trap from the device tells rConfig a change happened. The trap doesn’t carry the configuration: a matching filter queues a standard backup job, which then collects the device by its normal method.

Pull methods give rConfig control of timing and an immediate success or failure. Push suits devices that can only send files out, or that sit where rConfig can’t open a session to them. Triggers add timeliness to either.

The methods compared

Method	Direction and transport	What selects it	Best for	Main docs
CLI	rConfig to device, SSH or Telnet	Template `connect.protocol: ssh` or `telnet`, plus the device’s command group	Any device with a CLI over SSH or Telnet. The default.	Connection Templates
TL1	rConfig to an optical gateway, TL1 over SSH or raw TCP	Template `connect.protocol: tl1`	Ciena, Infinera and Cisco optical nodes, including elements reached in-band through a gateway	Optical TL1 guides
Script (SIE)	rConfig runs a script on its own server; the script reaches the device however it needs to	Template `connect.protocol: script`; the command in the command group is the script call	Devices without SSH or Telnet, proprietary interfaces, multi-step procedures	Script Integration Engine
API collection	rConfig to a REST API, HTTP GET or POST	An API collection (base URL, authentication type, credentials, endpoints), not a device record	Cloud platforms, SD-WAN controllers, SaaS services, anything with a configuration endpoint	API Collections
xFTP upload	Device to rConfig, TFTP, FTP, SFTP or SCP	Template `connect.protocol: xftp` for inbound-only devices; filename or a file matching rule links the upload to a device	Devices that push files, or that rConfig can’t connect out to	xFTP Server
SNMP trap	Device to rConfig, trap on UDP	A trap filter with a Download Configuration action, and device resolution	Capturing a change within seconds instead of waiting for the next schedule	SNMP Trap UI and Administration

For device records, the assigned connection template’s connect.protocol is the switch. There’s no separate device-level toggle: change the template and you change the method. API collections are the exception, because they are their own objects with their own credentials, scheduled through dedicated API task types rather than as devices.

Choosing a method

The device has a usable CLI over SSH or Telnet. Use CLI. The API Collections docs say the same: if a standard CLI connection works, back the target up as a regular device. The Connection Templates guides cover how to make it reliable.
The configuration lives behind a REST API. Use an API collection. One credential set in a collection authenticates every endpoint in it, and each endpoint is stored as its own file.
It’s an optical node speaking TL1. Use TL1. You add and collect the gateway; rConfig discovers the elements behind it and manages each as its own device.
Nothing standard fits. Use the Script Integration Engine. Your script does the talking, and its standard output becomes the configuration. The Script Integration Engine guides explain the design.
The device can only push, or can’t be reached from rConfig. Use xFTP with the inbound-only template.
You want changes captured as they happen. Add SNMP traps on top of a schedule. Traps complement scheduled backups rather than replace them: scheduled runs still catch changes that never raise a trap.

xFTP has a second use alongside CLI collection. An upload command in a device’s command group makes the device push a file (for example a binary or archive) to rConfig during a normal backup.

What changes with the method

The method decides more than the transport. It changes how failures surface and what you need to watch.

Method	How a failure shows up
CLI	One connection attempt per job, no automatic retry. The device is marked Config Failed and connection-failure notifications are sent.
TL1	An element reached through two or more gateways falls over to another path if a session through its primary gateway can’t be established.
Script (SIE)	The template’s failure criteria decide: failure exit codes, error patterns in the output, and required success patterns.
API collection	A retry count and delay per collection. From V8.4.2, any endpoint outside 200 to 299 marks the collection Down with a one-line reason, while the endpoints that worked are still saved.
xFTP inbound-only	No outbound run takes place, so nothing is marked Config Failed and no connection-failure notification is sent. Status comes from a ping check and from uploads arriving. Check the upload history to confirm delivery.
SNMP trap	Trap-triggered jobs have their own retry and backoff. A cooldown on each filter stops repeated backups from a burst of traps.

API and script output joins the same configuration history as CLI backups, so diff, search, compliance and change notifications apply to them too. xFTP uploads are moved into a per-device uploads folder by a scheduled sweep and appear in the device’s upload view.

Storage is a separate decision from collection. Turning off Keep Unchanged Config on a command discards a backup identical to the last one, while Config Hard Link keeps every version visible as a file and stores identical content once on disk.