Device Import Workbook

Successfully importing devices into rConfig requires careful planning and a systematic approach to managing dependencies. This workbook provides a structured methodology for designing, preparing, and executing device imports—whether onboarding a handful of devices or migrating thousands from legacy systems. The guidance here addresses the challenge of maintaining data consistency, establishing proper relationships between system components, and ensuring operational readiness from day one.

Organizations migrating from legacy configuration management tools face the additional complexity of data transformation and standardization. This workbook helps you leverage the migration process as an opportunity to improve naming conventions, refine organizational taxonomies, and align device attributes with current operational requirements. By following this structured approach, network teams can achieve faster time-to-value while building a foundation for long-term scalability.

Understanding Device Import Architecture

The Dependency Model

rConfig’s device management relies on a relational architecture where devices connect to multiple supporting components. Understanding these relationships is essential for successful imports, as missing or incorrectly configured dependencies will cause import failures or operational issues.

Why dependencies matter: Each device requires connections to vendors, templates, command groups, and optionally tags and credential sets. These relationships enable rConfig to determine how to connect to devices, what commands to execute, and how to organize the resulting configurations. Attempting to import devices without properly configured dependencies results in validation errors and failed imports.

Import sequence best practice: Always configure dependencies before importing devices. The recommended order ensures each component’s prerequisites exist when needed:

1. Vendors (no dependencies)
2. Templates (no dependencies)
3. Commands (no dependencies initially, later linked to command groups)
4. Command Groups (depends on commands)
5. Tags (no dependencies)
6. Credential Sets (no dependencies)
7. Devices (depends on all above components)

This sequence prevents circular dependency issues and allows for validation at each step before proceeding to the next layer.

Data Normalization and Standardization

Migration from legacy systems presents an opportunity to improve data quality and operational consistency. Organizations should use the import process to implement standardization across several key areas.

Naming convention evolution: Legacy systems often accumulate inconsistent naming patterns over years of operation. The import process enables enforcement of modern naming standards:

• Device names: Implement location-role-sequence format (e.g., NYC-CORE-RTR-01)
• Model designations: Standardize model strings to prevent duplication (CS1000 vs Cisco-1000 vs C1K)
• Template names: Use consistent platform-protocol format (Cisco-IOS-SSH, Juniper-Junos-SSH)
• Command group names: Align with network architecture terminology

Tag taxonomy design: Legacy category systems may not align with current operational needs. Design a comprehensive tag taxonomy that supports:

• Geographic organization (Region-EMEA, Site-London, Building-HQ)
• Environmental separation (Production, Staging, Development)
• Criticality tiers (Tier1-Critical, Tier2-Important, Tier3-Standard)
• Functional roles (Core, Distribution, Access, Security)
• Compliance requirements (PCI-DSS, HIPAA, SOX)

Credential consolidation: Rather than maintaining unique credentials per device, consolidate to role-based credential sets that simplify password rotation and reduce administrative overhead.

Tip

Migration Planning Tip: Export your legacy device inventory to spreadsheet format, apply standardization transformations using formulas and data validation, then import the cleaned data to rConfig. This approach allows bulk validation and correction before committing to the new system.

Section 1: Prerequisites for Device Setup

Before importing devices, establish the foundational components that devices will reference. This section provides detailed guidance on each prerequisite, including design considerations and best practices.

1.1 Vendors

Vendors identify device manufacturers and enable manufacturer-based filtering, reporting, and template associations.

Purpose and function: While vendor designation is required for each device, vendors primarily serve organizational purposes rather than functional requirements. The vendor association enables filtering device lists by manufacturer, generating vendor-specific reports, and associating devices with vendor-specific templates and command sets.

Design considerations:

• Use official manufacturer names for consistency (Cisco, not Cisco Systems Inc.)
• Include both hardware vendors and virtual appliance providers
• Consider subsidiary relationships (Arista vs Arista Networks)
• Plan for multi-vendor platforms (white-box switches with multiple OS options)

Vendor table structure:

ID	Vendor Name	Use Cases	Notes
1	Cisco	Enterprise routing, switching, security	Primary vendor for campus infrastructure
2	Juniper	Core routing, data center switching	Secondary vendor for DC fabric
3	Palo Alto	Next-gen firewalls	Security infrastructure
4	Arista	Data center leaf-spine	Cloud-scale networking
5	F5	Application delivery controllers	Load balancing infrastructure

Import preparation:

1. Extract unique vendor list from legacy system
2. Standardize vendor names to official designations
3. Add vendors via the rConfig UI before device import
4. Document vendor ID mappings for device import reference

1.2 Connection Templates

Templates define the connection protocols, authentication methods, and access parameters required to interact with devices. Templates are the most critical prerequisite—devices cannot function without properly configured templates.

Purpose and function: Templates specify how rConfig connects to devices (SSH, Telnet, SNMP), what authentication credentials to use, and how to navigate device CLI interfaces. Each device must reference exactly one template, making template design crucial for successful device operations.

Design considerations:

• Create platform-specific templates for major device types (Cisco IOS, Juniper Junos, Palo Alto PAN-OS)
• Include protocol variations (SSH standard port vs non-standard port)
• Consider security zone requirements (management VLAN vs production VLAN may use different templates)
• Plan for privilege escalation requirements (enable mode for Cisco devices)

Template table structure:

ID	Template Name	Connection Type	Port	Timeout	Notes
1	Cisco-IOS-SSH	SSH	22	30s	Standard Cisco IOS devices
2	Cisco-IOS-SSH-Alt	SSH	2222	30s	Non-standard SSH port
3	Juniper-Junos-SSH	SSH	22	45s	Juniper devices (longer timeout)
4	PaloAlto-SSH	SSH	22	30s	Palo Alto firewalls
5	Generic-Telnet	Telnet	23	20s	Legacy devices (use sparingly)

Template file preparation: For advanced templates requiring custom connection logic, prepare template YAML files before import:

cisco-ios-ssh.yaml

name: Cisco-IOS-SSH
connection_type: ssh
port: 22
timeout: 30
enable_mode: true
prompts:
  main: ".*[>#]"
  enable: ".*#"
authentication:
  method: password
  enable_required: true

Caution

Security Consideration: Avoid using Telnet templates except for legacy devices that don’t support SSH. Telnet transmits credentials in cleartext, creating significant security risks. Plan SSH migration for any devices currently using Telnet.

Import preparation:

1. Identify unique platform-protocol combinations in device inventory
2. Create or upload template files for each combination
3. Test templates against representative devices before bulk import
4. Document template ID mappings for device import reference

1.3 Commands

Commands define the specific CLI instructions executed on devices to retrieve configurations and operational data. Commands are later organized into command groups, but can be created independently first.

Purpose and function: Commands specify the exact syntax executed on device CLI interfaces. A comprehensive command library ensures complete configuration backup and operational visibility. Commands can be reused across multiple command groups, promoting efficiency.

Design considerations:

• Include configuration retrieval commands (show running-config, show startup-config)
• Add operational visibility commands (show version, show inventory, show interfaces)
• Consider vendor-specific command variations (show run vs display current-configuration)
• Plan for incremental configuration commands (show running-config changes)

Command table structure:

ID	Command	Description	Vendor Compatibility	Notes
1	show running-config	Full running configuration	Cisco IOS, IOS-XE	Primary backup command
2	show startup-config	Saved configuration	Cisco IOS, IOS-XE	Validation command
3	show version	Software version and hardware	Cisco IOS, IOS-XE	Device inventory
4	show ip interface brief	Interface summary	Cisco IOS, IOS-XE	Quick status check
5	show configuration	Full configuration	Juniper Junos	Primary backup command
6	show system information	System details	Palo Alto PAN-OS	Device inventory

Command group associations: Commands will later be associated with command groups. Plan which commands belong to which groups:

• Core-Switches: Commands 1, 2, 3, 4 (Cisco-focused configuration and status)
• Data-Center-Fabric: Commands 5 (Juniper-focused configuration)
• Firewalls: Command 6 (Palo Alto-focused)

Import preparation:

1. Extract command lists from legacy system or create from scratch
2. Standardize command syntax and descriptions
3. Add commands via the rConfig UI
4. Document command ID mappings and planned command group associations

1.4 Command Groups

Command groups organize related commands for execution against specific device types. Devices are assigned to exactly one command group, which determines which commands execute during configuration downloads.

Purpose and function: Command groups link devices to appropriate command sets based on device role or platform. A core router command group might include routing-specific commands, while an access switch command group focuses on VLAN and port configuration commands.

Design considerations:

• Align command groups with network architecture layers (Core, Distribution, Access)
• Consider device functional roles (Routing, Switching, Security, Wireless)
• Plan for platform-specific command groups when command syntax differs significantly
• Balance granularity (many specific groups) vs simplicity (fewer general groups)

Command group table structure:

ID	Group Name	Description	Command IDs	Device Types
1	Core-Switches	Commands for core switching	1, 2, 3, 4	Cisco core switches
2	Access-Switches	Commands for access layer	1, 2, 3, 4	Cisco access switches
3	Core-Routers	Commands for core routing	1, 2, 3	Cisco routers
4	Data-Center-Fabric	Commands for DC fabric	5	Juniper QFX series
5	Firewalls	Commands for firewalls	6	Palo Alto firewalls

Command group design example:

Network Architecture Mapping:

Core Layer
├── Core-Routers (Group ID: 3)
│   └── Commands: show run, show startup, show version
└── Core-Switches (Group ID: 1)
    └── Commands: show run, show startup, show version, show ip int brief

Distribution Layer
├── Distribution-Switches (Group ID: 6)
    └── Commands: show run, show version, show spanning-tree

Access Layer
├── Access-Switches (Group ID: 2)
    └── Commands: show run, show version, show interface status

Import preparation:

1. Map device types to command requirements
2. Create command groups aligned with network architecture
3. Associate commands with appropriate groups (many-to-many relationship)
4. Add command groups via the rConfig UI
5. Document command group ID mappings for device import reference

1.5 Tags

Tags provide flexible, multi-dimensional categorization for devices. Unlike command groups (one-per-device), devices can have multiple tags, enabling cross-cutting organizational capabilities.

Purpose and function: Tags enable filtering, reporting, and automation based on attributes that cross traditional hierarchical boundaries, without rigid structural constraints.

Design considerations:

• Plan multi-dimensional taxonomy (geography, environment, criticality, function)
• Establish naming conventions to prevent tag proliferation
• Balance specificity (London-HQ-Building-A) vs simplicity (London)

Tag table structure:

ID	Tag Name	Category	Description
1	Core	Function	Core infrastructure devices
2	Access	Function	Access layer devices
3	Production	Environment	Production environment
4	Staging	Environment	Staging environment
5	Region-EMEA	Geography	EMEA region devices
6	Region-AMER	Geography	Americas region devices
7	Tier1-Critical	Criticality	Mission-critical devices
8	PCI-Scope	Compliance	PCI-DSS compliance scope

Tag taxonomy design example:

Recommended Tag Structure:

Geographic Tags:
- Region-EMEA, Region-AMER, Region-APAC
- Country-UK, Country-US, Country-SG
- Site-London, Site-NewYork, Site-Singapore

Environmental Tags:
- Production, Staging, Development, DR

Criticality Tags:
- Tier1-Critical, Tier2-Important, Tier3-Standard

Functional Tags:
- Core, Distribution, Access, DMZ, Management

Compliance Tags:
- PCI-DSS, HIPAA, SOX, GDPR

Import preparation:

1. Design comprehensive tag taxonomy aligned with operational needs
2. Extract device attributes from legacy system for tag assignment
3. Add tags via the rConfig UI
4. Document tag ID mappings for device import reference

1.6 Device Credentials

Credential sets provide secure storage of device authentication information. Rather than storing credentials per-device, credential sets enable reuse across device populations.

Purpose and function: Credential sets store usernames, passwords, and enable passwords for device authentication. Devices can reference credential sets or use device-specific credentials. Credential set usage significantly simplifies password rotation and reduces security risks.

Design considerations:

• Create role-based credential sets (Core-Device-Creds, Access-Device-Creds)
• Plan for security zone separation (DMZ-Creds vs Internal-Creds)
• Consider compliance requirements (PCI devices may require separate credentials)
• Implement credential rotation schedule aligned with security policy

Credential table structure:

ID	Credential Name	Username	Password	Enable Password	Description	Devices
1	Core-Device-Creds	core-admin	●●●●●●	●●●●●●	Core infrastructure devices	50
2	Access-Device-Creds	access-admin	●●●●●●	●●●●●●	Access layer devices	200
3	Firewall-Creds	fw-admin	●●●●●●	N/A	Firewall devices	15
4	DMZ-Creds	dmz-admin	●●●●●●	●●●●●●	DMZ segment devices	25
5	Readonly-Creds	readonly-user	●●●●●●	N/A	Read-only access	10

Credential security considerations:

• Encryption at rest: rConfig encrypts stored credentials using AES-256
• Access control: Limit credential visibility to authorized administrators
• Rotation schedule: Implement quarterly rotation minimum, monthly for critical infrastructure
• Audit trail: Monitor credential usage through activity logs
• Emergency access: Maintain separate “break-glass” credentials with strict audit requirements

Caution

Security Warning: Never store credentials in unencrypted spreadsheets or external systems during import preparation. Use rConfig’s encrypted credential storage exclusively. When preparing import files, reference credential set IDs rather than including passwords in CSV files.

Import preparation:

1. Identify unique credential requirements across device population
2. Create consolidated credential sets for device roles
3. Add credentials via rConfig UI (never via API for security)
4. Document credential ID mappings for device import reference
5. Plan credential rotation schedule post-import

1.7 Model Naming Standardization

Consistent model designation ensures accurate inventory tracking, reporting, and operational clarity. Model standardization prevents duplication and enables efficient device lifecycle management.

Purpose and function: Model names identify specific device hardware or software platforms. Standardized model naming enables accurate inventory reports, warranty tracking, and capacity planning. Model names also assist in template and command group assignment.

Design considerations:

• Standardize model format (manufacturer-series-model: Cisco-Catalyst-9300)
• Handle vendor variations (C9300 vs Catalyst-9300 vs WS-C9300)
• Include platform designations for virtual devices (Cisco-CSR1000V)
• Document model-to-template mappings for consistent configuration

Model standardization examples:

Legacy Model Name	Standardized Model	Notes
C3850, Cat3850, WS-C3850	Cisco-Catalyst-3850	Consolidate variations
ASR1K, ASR-1000	Cisco-ASR-1000	Standardize format
SRX-345	Juniper-SRX-345	Add vendor prefix
PA-220	PaloAlto-PA-220	Standardize vendor name
vSRX	Juniper-vSRX	Virtual platform designation

Import preparation:

1. Extract unique model list from legacy device inventory
2. Identify model name variations requiring consolidation
3. Create model standardization mapping table
4. Apply transformations during import file preparation
5. Document model standards for future device additions

Section 2: Device Import Methods

rConfig provides multiple methods for adding devices to the inventory. Understanding when to use each method ensures efficient onboarding aligned with your operational requirements.

Import Method Selection

Manual Addition

Manual Device Entry

When to use:

• Adding 1-10 devices
• Unique or specialized devices requiring careful configuration
• Training and system familiarization
• Proof-of-concept environments

Process:

1. Navigate to Devices → Add Device
2. Complete all required fields
3. Select prerequisite components (vendor, template, command group)
4. Assign optional tags and credentials
5. Submit and verify initial configuration download

Advantages:

• Complete control over each field
• Immediate validation feedback
• Ideal for learning device structure
• No preparation overhead

Limitations:

• Time-consuming for multiple devices
• Prone to manual entry errors
• Not suitable for bulk operations

Device Cloning

Clone Existing Devices

When to use:

• Adding 10-50 similar devices
• Standardized equipment deployments
• Branch office rollouts with identical configuration
• Stack member additions

Process:

1. Locate similar existing device in device table
2. Click dropdown → Clone
3. Modify device-specific fields (name, IP address)
4. Submit and verify initial configuration download

What gets cloned:

• Template and credential references
• Command group assignment
• Vendor and model information
• Tag associations
• Port and prompt configurations

What requires manual entry:

• Device name (must be unique)
• IP address (must be unique)
• Device-specific customizations

Advantages:

• Rapid deployment of similar devices
• Reduced configuration errors through reuse
• Maintains consistency across device populations

Limitations:

• Requires representative device to clone from
• Still manual process (not suitable for hundreds of devices)

CSV Import

Bulk Import from CSV

When to use:

• Migrating from legacy systems (50+ devices)
• Initial rConfig population with large device inventory
• Periodic bulk updates from authoritative data sources
• Standardized deployments at scale (100-5,000 devices)

Process:

1. Download CSV template from Settings → Import/Export
2. Populate template with device data and prerequisite IDs
3. Validate data completeness and accuracy
4. Upload CSV file through import interface
5. Review validation results and address errors
6. Confirm import and monitor job progress

CSV template structure:

device_name,device_ip,device_username,device_password,device_enable_password,device_main_prompt,device_enable_prompt,device_category_id,device_template,device_model,device_vendor,device_tag,device_default_creds_on,device_cred_id
CoreSwitch01,192.168.1.1,admin,s3cret,en4ble,>,#,1,1,Cisco-Catalyst-3850,1,"1,2",0,0
AccessSwitch01,192.168.2.1,,,,>,#,2,1,Cisco-Catalyst-2960,1,"2,5",1,2

Tip

The Import & Export page is the canonical reference for the import column headers and how each row is validated. Always download the template from Settings → Import / Export so your headers match the importer exactly.

Advantages:

• Handles hundreds to thousands of devices efficiently
• Enables data validation and transformation in spreadsheet tools
• Supports bulk updates to existing devices
• Repeatable process for periodic synchronization

Limitations:

• Requires prerequisite preparation (all IDs must exist)
• Complex validation requirements
• Limited to 500 devices per file for optimal performance

Import best practices:

1. Validate all prerequisite IDs exist before import
2. Use spreadsheet formulas for data transformation and validation
3. Test import with subset (10-20 devices) before full import
4. Schedule large imports during off-peak hours
5. Monitor queue manager and activity logs for import progress

Import Method Decision Matrix

Scenario	Recommended Method	Scale	Effort
Initial setup, learning	Manual	1-10	Low
Similar device additions	Clone	10-50	Low
Legacy system migration	CSV Import	50-5,000	Medium

Section 3: CSV Import Preparation

CSV import is the most common method for bulk device onboarding and legacy system migration. This section provides detailed guidance on preparing import files for successful execution.

Download and Understand the Template

rConfig provides a CSV template with all required and optional fields pre-configured. This template serves as the foundation for import preparation.

Obtaining the template:

1. Navigate to Settings → Import/Export
2. Click “Download Device Import Template”
3. Save CSV template to working directory
4. Review field headers and example rows

Template structure overview:

The template includes the following column categories:

Required columns (must not be blank, and ID columns must reference existing records):

• device_name: Unique device name (invalid characters are stripped on import)
• device_ip: Valid IPv4 or IPv6 address
• device_main_prompt: Device CLI prompt
• device_enable_prompt: Privilege mode prompt
• device_model: Device model designation (free text)
• device_category_id: Reference to a Command Group
• device_template: Reference to a connection Template
• device_vendor: Reference to a Vendor
• device_tag: Tag ID or comma-separated Tag IDs (e.g., “1,2,5”)
• device_default_creds_on: 1 to use a saved credential set, 0 to use inline credentials
• device_cred_id: Saved credential set ID when device_default_creds_on is 1, otherwise 0

Optional columns (used only when device_default_creds_on is 0):

• device_username: Inline username
• device_password: Inline password (stored encrypted)
• device_enable_password: Inline enable password (stored encrypted)

Data Preparation Workflow

Successful CSV import requires systematic data preparation addressing validation, transformation, and quality assurance.

Step 1: Extract Legacy Data

Export device inventory from legacy system to spreadsheet format:

• Include all device attributes available
• Export supporting data (vendors, tags, credentials if possible)
• Preserve any existing organizational structure
• Document data format and field meanings

Step 2: Create Prerequisite Mapping Tables

Build reference tables mapping legacy values to rConfig IDs:

Vendor mapping example:

Legacy Vendor | rConfig Vendor | Vendor ID
-------------|---------------|----------
Cisco        | Cisco         | 1
Jun          | Juniper       | 2
PA           | Palo Alto     | 3

Template mapping example:

Legacy Template | Device Types       | rConfig Template    | Template ID
---------------|-------------------|-------------------|------------
ssh_cisco      | IOS, IOS-XE       | Cisco-IOS-SSH     | 1
ssh_juniper    | Junos            | Juniper-Junos-SSH | 2
ssh_paloalto   | PAN-OS           | PaloAlto-SSH      | 3

Command group mapping example:

Legacy Category | Device Role    | rConfig Command Group | CG ID
---------------|---------------|---------------------|------
core_switches  | Core switching | Core-Switches       | 1
access_layer   | Access layer   | Access-Switches     | 2

Step 3: Transform and Standardize Data

Apply transformations to align legacy data with rConfig standards:

Device name standardization:

=UPPER(SUBSTITUTE(TRIM(A2)," ","-"))
# Converts "core switch 01" to "CORE-SWITCH-01"

IP address validation:

=IF(AND(LEN(B2)>6,ISNUMBER(FIND(".",B2))),B2,"INVALID")
# Flags invalid IP addresses for review

Model standardization:

=VLOOKUP(C2,ModelMapping!A:B,2,FALSE)
# Maps legacy model names to standardized format

Tag ID compilation (if tags stored in separate columns):

=TEXTJOIN(",",TRUE,IF(D2="Core","1",""),IF(E2="Production","3",""))
# Combines tag assignments into comma-separated ID list

Step 4: Populate Import Template

Map transformed data to rConfig template columns:

1. Copy device_name from standardized names
2. Copy device_ip from validated IPs
3. VLOOKUP device_vendor from vendor mapping table
4. VLOOKUP device_template from template mapping table
5. VLOOKUP device_category_id from command group mapping
6. Compile device_tag from tag assignments
7. Set device_default_creds_on and either device_cred_id or the inline credential columns
8. Add device_model, device_main_prompt, and device_enable_prompt

Step 5: Validate Import Data

Perform comprehensive validation before import:

Required field validation:

=IF(OR(ISBLANK(A2),ISBLANK(B2),ISBLANK(C2),ISBLANK(D2),ISBLANK(E2)),"MISSING REQUIRED","OK")
# Flags rows with missing required fields

ID existence validation:

• Cross-reference device_vendor against the vendor table
• Cross-reference device_template against the template table
• Cross-reference device_category_id against the command group table
• Validate device_tag IDs exist (split comma-separated values and check each)

Data format validation:

• Device names: No spaces, minimum 3 characters, alphanumeric with dash/dot/underscore only
• IP addresses: Valid IPv4 or IPv6 format
• Port numbers: Numeric, range 1-65535
• Tag IDs: Comma-separated numeric values with no spaces

Example Import File

Complete import CSV example:

device_name,device_ip,device_username,device_password,device_enable_password,device_main_prompt,device_enable_prompt,device_category_id,device_template,device_model,device_vendor,device_tag,device_default_creds_on,device_cred_id
NYC-CORE-RTR-01,192.168.1.1,admin,s3cret,en4ble,>,#,1,1,Cisco-ASR-1000,1,"1,3,7",0,0
NYC-CORE-SW-01,192.168.1.2,,,,>,#,2,1,Cisco-Catalyst-9500,1,"1,3,7",1,1
LON-ACCESS-SW-01,192.168.2.10,,,,>,#,3,1,Cisco-Catalyst-2960X,1,"2,3,5",1,2
SFO-FW-DMZ-01,192.168.10.1,admin,s3cret,en4ble,>,#,5,4,PaloAlto-PA-3020,3,"7,8",0,0

Field breakdown for first device (NYC-CORE-RTR-01):

Field	Value	Explanation
device_name	NYC-CORE-RTR-01	Standardized naming: Location-Role-Type-Sequence
device_ip	192.168.1.1	Management interface IP
device_vendor	1	References Cisco vendor (ID 1)
device_template	1	References Cisco-IOS-SSH template (ID 1)
device_tag	”1,3,7”	Core (1), Production (3), Tier1-Critical (7)
device_category_id	1	Core-Routers command group
device_model	Cisco-ASR-1000	Standardized model designation
device_main_prompt	”>“	User mode prompt
device_enable_prompt	”#“	Privilege mode prompt
device_default_creds_on	0	Use the inline username and password on this row
device_cred_id	0	Not used because inline credentials are supplied

Note

CSV Formatting Note: When device_tag or any field contains commas, enclose the value in double quotes (“1,3,7”). This prevents the CSV parser from interpreting the commas as field separators. Excel and most spreadsheet tools handle this automatically when saving to CSV format.

Import Validation Checklist

Before uploading your CSV file, verify completion of all validation steps:

Prerequisite validation:

• All device_vendor values exist in rConfig vendor table
• All device_template values exist in rConfig template table
• All device_category_id values exist in rConfig command group table
• All device_cred_id values exist in rConfig credential table (when device_default_creds_on is 1)
• All device_tag values exist in rConfig tag table

Required field validation:

• Every row has device_name, device_ip, device_main_prompt, device_enable_prompt, and device_model
• Every row has device_category_id (numeric, valid reference)
• Every row has device_template (numeric, valid reference)
• Every row has device_vendor (numeric, valid reference)
• Every row has device_tag (one or more valid Tag IDs)

Credential validation:

• device_default_creds_on is set to 0 or 1 on every row
• Rows using a saved credential set have a valid device_cred_id
• Rows using inline credentials provide device_username, device_password, and device_enable_password

Data quality validation:

• Device names follow organizational naming convention
• IP addresses reachable from rConfig server
• No duplicate device names in import file
• No duplicate IP addresses in import file
• Models standardized according to naming convention

Section 4: Executing the Import

With prerequisites configured and CSV file prepared, execute the import process through rConfig’s import interface.

Step-by-Step Import Execution

Step 1: Access Import Interface

1. Navigate to Settings → Import/Export
2. Locate the Device Import section
3. Review any system messages or warnings
4. Ensure sufficient system resources for import size

Step 2: Upload Import File

1. Click “Choose File” or “Browse” button
2. Select prepared CSV file from local system
3. Verify file name displayed correctly
4. Review file size and estimated device count

Step 3: Import and Review Results

Choose Import Devices. rConfig validates and imports in a single action, there is no separate options screen or confirm step.

• Each row is validated in order. Valid rows are created immediately as new devices.
• Any row that fails a check is skipped and added to a warnings list with the exact reason, for example Import Error device5: Invalid Template ID.
• A summary such as 3 Devices successfully imported is shown, and every event is written to the Application Log.

For the full list of validation checks and their messages, see the Import & Export reference.

Note

The importer always creates new devices, it does not update or de-duplicate existing ones, and it does not start configuration downloads. Imported devices begin with a status of Unknown until rConfig first reaches them. After importing, select the new devices on the Devices page to download configurations.

Post-Import Verification

After successful import, perform verification steps to ensure devices operational:

Immediate verification:

1. Review device table: Navigate to Devices page, verify imported devices appear
2. Check device count: Confirm total device count matches import expectations
3. Spot check devices: Open several device detail pages, verify all attributes correct
4. Verify tag assignments: Use tag filters to confirm tag associations

Configuration download verification:

If immediate downloads enabled, monitor initial configuration retrieval:

1. Navigate to Queue Manager
2. Filter jobs by status (Running, Pending, Failed)
3. Review failed downloads for credential or connectivity issues
4. Check Activity Logs for detailed error messages

Troubleshooting initial download failures:

Issue	Symptom	Resolution
Authentication failure	”Authentication failed” in logs	Verify credentials correct, test manual SSH/Telnet
Network unreachable	”Connection timeout” in logs	Verify IP reachable, check firewall rules
Prompt mismatch	”Timeout waiting for prompt”	Correct main/enable prompt configuration
Template misconfiguration	Immediate failure on connection	Review template settings, test against device

Bulk download scheduling:

For imports with immediate downloads disabled, schedule configuration retrieval:

1. Select imported devices in device table (filter by import date/time)
2. Choose bulk action: “Download Configurations”
3. Schedule job execution (immediately or specific time)
4. Monitor queue manager for job progress

Caution

Performance Consideration: Downloading configurations from 100+ devices simultaneously can impact system performance and network bandwidth. For large device populations, implement staggered downloads using multiple scheduled jobs (e.g., 100 devices every 30 minutes) or utilize queue worker scaling to distribute load.

Section 5: Post-Import Actions and Optimization

Successful import is only the beginning. Post-import optimization ensures long-term operational efficiency and data quality.

Immediate Post-Import Tasks

Address failed imports: Review import summary and address any failed devices:

1. Export failed device list from import summary
2. Identify root causes (missing prerequisites, validation errors)
3. Correct issues in original CSV or prerequisites
4. Re-import corrected device subset

Configure scheduled downloads: Establish regular configuration backup schedules:

1. Navigate to Scheduled Jobs
2. Create download schedule aligned with change control windows
3. Configure frequency based on device criticality (daily for Tier1, weekly for Tier3)
4. Enable email notifications for failed downloads

Document import results: Maintain import documentation for audit and operational reference:

• Import date and time
• Import file name and location
• Device count (total, successful, failed)
• Prerequisite IDs used (vendors, templates, command groups, credentials, tags)
• Any issues encountered and resolutions applied
• Next steps and follow-up actions required

Section 6: Common Issues and Troubleshooting

Understanding common import issues and their resolutions accelerates troubleshooting and reduces import failures.

Import Validation Failures

Missing Prerequisites

Prerequisite ID Does Not Exist

Symptom: A skipped row with Import Error {name}: Invalid Category ID, Invalid Vendor ID, Invalid Template ID, Invalid Tag ID, or Invalid Credentials ID

Cause: The row references a prerequisite ID (device_category_id, device_vendor, device_template, device_tag, or device_cred_id) that does not exist in rConfig yet

Resolution:

1. Read the skipped row warnings (and the Application Log) to identify which ID is missing
2. Create the missing prerequisite:
   • Vendors: Vendors
   • Templates: Templates
   • Command Groups: Command Groups
   • Credentials: Settings → Device Credentials
   • Tags: Tags
3. Update the file with the correct IDs
4. Re-upload

Prevention: Create and document all prerequisites before preparing the import file. Maintain prerequisite ID mapping tables for reference during preparation.

Blank Required Fields

A Required Field Is Empty

Symptom: A skipped row with Import Error {name}: Blank Fields

Cause: One of the required columns is empty on that row. The required columns are device_name, device_ip, device_main_prompt, device_enable_prompt, device_model, device_category_id, device_template, device_vendor, and device_tag.

Resolution:

1. Open the file and locate the named device
2. Fill any empty required cell (use placeholder text where a value does not apply, for example for an unused enable prompt)
3. Re-upload

Prevention: Use spreadsheet data validation to flag empty required cells before saving the file.

Duplicate Devices

Duplicates Are Not Detected

Important: The importer always creates new devices. It does not check for existing devices and has no update mode, so a name or IP that already exists will result in a second, duplicate device.

Resolution:

1. Before importing, remove rows for devices that already exist in rConfig
2. De-duplicate device_name and device_ip within the file itself
3. If duplicates were imported, delete the extra devices from the Devices page

Prevention: Query existing devices before preparing the import and keep device names unique and standardized.

Device Names

Invalid Characters in Device Names

Behaviour: Device names are sanitized automatically on import. Any character that is not a letter, number, dot, dash, or underscore is stripped, so Core Switch 01 becomes CoreSwitch01. Rows are not rejected for this.

Resolution:

• If the sanitized name is not what you expected, correct device_name in the file (remove spaces and special characters yourself) and re-import
• Keep names unique after sanitization to avoid accidental near-duplicates

Post-Import Configuration Issues

Authentication Failures

Devices Fail Initial Download - Authentication

Symptom: Activity logs show “Authentication failed” for newly imported devices

Diagnostic steps:

1. Verify credentials correct in rConfig (credential set or inline)
2. Test credentials manually via SSH/Telnet to affected device
3. Check for credential typos or incorrect enable passwords
4. Verify device not using different credentials than specified

Resolution:

• Update device credentials if incorrect
• Re-test manual download after credential correction
• If multiple devices affected, consider credential set issue
• Verify credential set hasn’t been modified since import

Connection Failures

Devices Fail Initial Download - Connectivity

Symptom: Activity logs show “Connection timeout” or “Network unreachable”

Diagnostic steps:

1. Verify IP address correct and reachable from rConfig server:

   ping <device_ip>

2. Check firewall rules between rConfig server and device
3. Verify correct port (SSH typically 22, Telnet typically 23)
4. Test manual connection from rConfig server:

   ssh username@device_ip
   telnet device_ip port

Resolution:

• Correct IP addresses if incorrect
• Add rConfig server IP to device management ACLs
• Update firewall rules allowing rConfig → device communication
• Verify port configuration matches actual device service

Prompt Detection Failures

Devices Fail Initial Download - Prompt Timeout

Symptom: Activity logs show “Timeout waiting for prompt” or prompt detection errors

Diagnostic steps:

1. Review device logs for actual prompt strings
2. Compare actual prompts with configured main_prompt and enable_prompt
3. Test manual connection noting exact prompt strings
4. Check for dynamic hostname in prompt (varies by device)

Resolution:

For exact prompt mismatch:

• Update main_prompt to match actual device prompt exactly
• Include hostname if static: “router01>” or “router01#”
• Update enable_prompt for privilege mode prompt

For dynamic prompts:

• Use regex patterns accommodating variations
• Example: .*[>#] matches any prompt ending in > or #
• Test regex pattern against known prompt variations

For complex prompts:

• Consult Device Prompts Documentation
• Consider template modifications for platform-specific handling
• Test prompt detection with debug command:

  cd /var/www/html/rconfig
  php artisan rconfig:download-device 1234 -d

Performance and Scale Issues

Import performance degradation: For very large imports (1,000+ devices), consider these optimizations:

• Split import into multiple files (500 devices per file maximum)
• Schedule imports during off-peak hours
• Disable immediate downloads, schedule separately
• Monitor system resources during import (CPU, memory, disk I/O)

Queue congestion after import: If hundreds of downloads queued simultaneously:

• Pause queue workers temporarily
• Implement staggered download scheduling
• Scale queue workers to handle load (1 worker per 500 devices)
• Prioritize critical devices for immediate download

Database performance: After importing thousands of devices:

• Run database optimization if query performance degrades
• Contact rConfig support for deployments exceeding 5,000 devices
• Consider enterprise architecture consultation for large-scale deployments

Section 7: Best Practices and Recommendations

Import Planning Best Practices

Start small, scale gradually:

• Begin with pilot import (10-20 devices) validating process end-to-end
• Expand to larger subset (100 devices) refining approach
• Execute full import only after successful validation

Maintain data quality at source:

• Clean and standardize data before import, not after
• Leverage spreadsheet tools for bulk transformations
• Implement validation formulas catching errors during preparation

Document everything:

• Maintain prerequisite ID mapping tables
• Document naming conventions and standards
• Record lessons learned for future imports
• Create runbooks for repeatable import processes

Test thoroughly:

• Validate credentials against actual devices before import
• Test templates with representative devices from each platform
• Verify network connectivity from rConfig server to device subnets
• Run pilot imports identifying issues before full-scale execution

Operational Excellence

Establish data governance:

• Define standards for device naming, model designation, tagging
• Implement approval workflows for prerequisite creation
• Schedule regular data quality audits
• Enforce standards through validation and training

Implement continuous improvement:

• Collect metrics on import success rates and common failures
• Refine import processes based on operational experience
• Update documentation reflecting current best practices
• Train team members on import procedures and troubleshooting

Plan for scale:

• Design tag taxonomy supporting future growth
• Create reusable credential sets reducing administrative overhead
• Establish template library covering current and future platforms
• Split very large inventories into multiple import files

Security Considerations

Credential management:

• Never store credentials in unencrypted files during import preparation
• Use credential sets instead of inline credentials when possible
• Implement credential rotation schedule post-import
• Audit credential usage through activity logs

Access control:

• rConfig V8 Core does not use per-user roles, so all authenticated users have the same access to imported devices
• Restrict who can sign in to rConfig and review the Application Log for import activity
• Regularly audit access patterns for anomalies

Data protection:

• Secure import files containing device data and credentials
• Delete import files after successful import
• Maintain audit trail of all import activities
• Implement backup procedures for rConfig database

Section 8: Quick Reference

Import Workflow Checklist

Pre-Import Phase:

• Create and document all vendors
• Create and test all connection templates
• Create and organize all commands
• Create and configure all command groups
• Design and create tag taxonomy
• Create credential sets for device roles
• Document all prerequisite IDs for reference

CSV Preparation Phase:

• Download CSV template from rConfig
• Extract device data from legacy system or source
• Create prerequisite mapping tables (vendor, template, command group, etc.)
• Transform and standardize device data
• Populate CSV template with transformed data
• Validate all required fields present and formatted correctly
• Validate all prerequisite IDs exist in rConfig
• Test pilot import with 10-20 device subset

Import Execution Phase:

• Access Settings → Import/Export
• Upload prepared file (.csv or .xlsx, up to 2 MB)
• Choose Import Devices
• Review the import summary and the skipped-row warnings
• Correct any skipped rows in the file and re-import

Post-Import Phase:

• Verify devices appear in device table
• Spot-check device attributes for accuracy
• Download configurations on sample devices from the Devices page
• Address authentication, connectivity, or prompt detection issues
• Schedule ongoing configuration backup jobs
• Document import results and lessons learned

CSV Template Field Reference

Field	Required	Format	Notes
device_name	Yes	Letters, numbers, _ . -	Invalid characters are stripped on import
device_ip	Yes	Valid IPv4/IPv6	Management IP address
device_main_prompt	Yes	Text	Device CLI prompt for detection
device_enable_prompt	Yes	Text	Privilege mode prompt (placeholder if unused)
device_model	Yes	Text	Free text model designation
device_category_id	Yes	Numeric	Must reference an existing Command Group
device_template	Yes	Numeric	Must reference an existing Template
device_vendor	Yes	Numeric	Must reference an existing Vendor
device_tag	Yes	Numeric or comma-separated (“1,2,3”)	All IDs must exist in the tags table
device_default_creds_on	Yes	0 or 1	1 uses a saved credential set, 0 uses inline credentials
device_cred_id	Yes	Numeric	Saved credential set ID when device_default_creds_on is 1, otherwise 0
device_username	No*	Text	Used only when device_default_creds_on is 0
device_password	No*	Text	Used only when device_default_creds_on is 0 (stored encrypted)
device_enable_password	No*	Text	Used only when device_default_creds_on is 0 (stored encrypted)

*Inline credential columns apply only when device_default_creds_on is 0.

Troubleshooting Quick Reference

Issue	Quick Check	Quick Fix
Skipped: Invalid Category/Vendor/Template/Tag/Credentials ID	Verify the ID exists in rConfig	Create the prerequisite, update the file with the correct ID
Skipped: Blank Fields	Check all required columns are filled	Populate the empty cell and re-import
Duplicate device created	Check for an existing device with the same name/IP	The importer does not de-duplicate; remove the row first, or delete the duplicate afterwards
Import: Authentication failure	Test credentials manually	Update device credentials
Import: Connection timeout	Ping device from rConfig server	Fix network/firewall, correct IP
Import: Prompt timeout	Review actual device prompt	Update prompt configuration to match

Summary and Key Takeaways

Successfully importing devices into rConfig requires systematic planning, careful data preparation, and thorough validation. This workbook has provided comprehensive guidance for each phase of the import process, from prerequisite planning through post-import optimization.

Critical success factors:

1. Prerequisites first: Always configure vendors, templates, commands, command groups, tags, and credential sets before attempting device import. Missing prerequisites cause validation failures and import delays.

2. Data standardization: Use the import process as an opportunity to standardize naming conventions, consolidate model designations, and implement consistent tagging taxonomies. Clean data at the source prevents operational issues downstream.

3. Validation is essential: Leverage comprehensive validation during CSV preparation and before import execution. Catching errors early reduces troubleshooting time and ensures successful imports.

4. Start small, scale gradually: Execute pilot imports validating the entire process before committing to large-scale imports. This approach identifies issues when they’re easiest to correct.

5. Post-import verification: Successful import is only the beginning. Verify configuration downloads, address authentication or connectivity issues promptly, and implement ongoing data quality processes.

Next steps:

• Use the Import & Export page reference for the exact import columns and export behaviour
• Review Devices for comprehensive device management guidance
• Consult Connection Templates for template configuration best practices
• Reference Device Prompts for prompt configuration troubleshooting

Enterprise support: Organizations importing thousands of devices, migrating from complex legacy systems, or requiring custom import workflows should engage rConfig enterprise support for migration planning, data transformation assistance, and architectural consultation.

By following the structured approach outlined in this workbook, network operations teams can achieve efficient, accurate device imports that establish a strong foundation for configuration management operations.

---

For additional help, see the rConfig V8 Core documentation, ask the community on GitHub, or contact support@rconfig.com. Advanced migration and import tooling is part of the Pro, Enterprise, and Vector editions, documented separately at docs.rconfig.com.