The manifest CSV format
The manifest is the contract between the generator and the server. It is a CSV that maps
every ip:port to its config file, credentials, vendor, and driver. rcfg-sim reads it at
startup to know what to bind and how each device should behave.
Schema
Section titled “Schema”The header (and column order) is:
hostname,ip,port,vendor,template,username,password,enable_password,config_file,size_bucket| Column | Meaning |
|---|---|
hostname |
The device’s hostname (shown in prompts and show version) |
ip |
IP the listener binds |
port |
Port the listener binds |
vendor |
Manifest vendor string (e.g. Cisco, Ciena) |
template |
Driver id — resolves the runtime driver (cisco_ios, junos, ciena_tl1, infinera_tl1, cisco_ons_tl1) |
username |
Accepted username for this device |
password |
Accepted password |
enable_password |
Enable-mode password |
config_file |
Absolute path to the .cfg this device serves |
size_bucket |
The model/bucket the device was generated from |
Example rows
Section titled “Example rows”hostname,ip,port,vendor,template,username,password,enable_password,config_file,size_bucketrtr-msp-hq-1000,10.50.0.1,10000,Cisco,cisco_ios,admin,admin,enable123,/opt/rcfg-sim/configs/device-00000.cfg,mdciena-lax-1001,10.50.0.1,10001,Ciena,ciena_tl1,admin,admin,enable123,/opt/rcfg-sim/configs/device-00001.cfg,ciena-6500-tl1Hand-rolling a manifest
Section titled “Hand-rolling a manifest”You can write a manifest by hand to build a precise, small fleet — useful for tests. As long
as the header matches and each config_file exists (or, for ciena_tl1, even if the payload
is absent — the driver synthesizes a small canned inventory), the server will serve it.
An empty template value falls back to the cisco_ios driver, so older manifests keep
working unchanged. A non-empty value that names no registered driver stops the server at
startup. The generator never writes junos; set it by hand for Junos devices, as the
mesh-campus scenario does.