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 rConfig UI or API 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 rConfig UI or API
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 rConfig UI or API
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. Tag-based RBAC also controls user access to device populations without rigid structural constraints.

Design considerations:

• Plan multi-dimensional taxonomy (geography, environment, criticality, function)
• Establish naming conventions to prevent tag proliferation
• Consider RBAC requirements (tags can inherit role assignments)
• Balance specificity (London-HQ-Building-A) vs simplicity (London)

Tag table structure:

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

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 rConfig UI or API
4. Document tag ID mappings for device import reference
5. Plan role assignments for RBAC-enabled tags

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,ip_address,vendor_id,template_id,tag_ids,command_group_id,credential_id,port,main_prompt,enable_prompt,model
CoreSwitch01,192.168.1.1,1,1,"1,2",1,1,22,">","#",Cisco-Catalyst-3850
AccessSwitch01,192.168.2.1,1,1,"2,5",2,2,22,">","#",Cisco-Catalyst-2960

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

REST API

Programmatic Import via API

When to use:

• Integration with CMDB or IPAM systems
• Continuous synchronization with authoritative data sources
• Automated provisioning workflows
• Custom migration scripts from legacy systems
• Unlimited scale (1,000+ devices)

Process:

1. Obtain API authentication credentials
2. Query prerequisites to obtain IDs (vendors, templates, etc.)
3. Construct device JSON payload with all required fields
4. POST to /api/devices endpoint
5. Handle validation errors and retry logic
6. Verify device creation and initial download

API request example:

{
  "device_name": "CoreSwitch01",
  "ip_address": "192.168.1.1",
  "vendor_id": 1,
  "template_id": 1,
  "command_group_id": 1,
  "tag_ids": [1, 2],
  "credential_id": 1,
  "port": 22,
  "main_prompt": ">",
  "enable_prompt": "#",
  "model": "Cisco-Catalyst-3850"
}

Advantages:

• Unlimited scale with proper rate limiting
• Real-time synchronization capabilities
• Programmatic error handling and retry logic
• Integration with existing automation workflows

Limitations:

• Requires API development skills
• Needs robust error handling implementation
• Rate limiting considerations for bulk operations
• More complex than CSV for one-time migrations

API best practices:

1. Implement exponential backoff for retry logic
2. Batch requests (50-100 devices per batch)
3. Validate responses and log errors comprehensively
4. Use API for continuous sync, CSV for one-time migrations
5. Monitor API rate limits and adjust request frequency

For detailed API documentation, see REST API Reference.

Third-Party Integration

Automated Integration

When to use:

• Existing network monitoring platform integration
• CMDB as single source of truth
• Cloud inventory synchronization
• Continuous automated discovery and onboarding

Supported integrations:

• Network monitoring: LibreNMS, Observium, PRTG
• IPAM systems: phpIPAM, NetBox
• CMDB platforms: ServiceNow, Device42
• Cloud platforms: AWS, Azure, GCP inventory

Process (varies by integration):

1. Configure integration credentials and API access
2. Define synchronization scope and filters
3. Map external system fields to rConfig attributes
4. Configure synchronization schedule
5. Monitor integration logs and address conflicts

Advantages:

• Automated synchronization eliminates manual updates
• Single source of truth maintained in external system
• Continuous device discovery and updates
• Reduced data entry errors

Limitations:

• Requires integration setup and configuration
• Field mapping complexity for attribute translation
• Potential for data conflicts requiring resolution logic
• Integration-specific troubleshooting requirements

For integration configuration, see Integrations Documentation.

Import Method Decision Matrix

Scenario	Recommended Method	Scale	Effort	Automation
Initial setup, learning	Manual	1-10	Low	None
Similar device additions	Clone	10-50	Low	Minimal
Legacy system migration	CSV Import	50-5,000	Medium	Partial
CMDB integration	REST API	Unlimited	High	Full
Continuous sync	Third-Party Integration	Unlimited	High	Full

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:

• device_name: Unique device identifier
• ip_address: Valid IPv4 or IPv6 address
• vendor_id: Reference to vendor prerequisite
• template_id: Reference to connection template
• command_group_id: Reference to command group

Optional columns:

• tag_ids: Comma-separated tag IDs (e.g., “1,2,5”)
• credential_id: Reference to credential set (or use inline credentials)
• port: Port override (leave empty for template default)
• main_prompt: Device CLI prompt (use for exact match)
• enable_prompt: Privilege mode prompt
• model: Device model designation
• username: Inline credential (if not using credential_id)
• password: Inline credential (if not using credential_id)
• enable_password: Inline enable credential

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 ip_address from validated IPs
3. VLOOKUP vendor_id from vendor mapping table
4. VLOOKUP template_id from template mapping table
5. VLOOKUP command_group_id from command group mapping
6. Compile tag_ids from tag assignments
7. Add credential_id or inline credentials
8. Add optional fields (port, prompts, model)

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 vendor_id against vendor table
• Cross-reference template_id against template table
• Cross-reference command_group_id against command group table
• Validate 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,ip_address,vendor_id,template_id,tag_ids,command_group_id,credential_id,port,main_prompt,enable_prompt,model
NYC-CORE-RTR-01,192.168.1.1,1,1,"1,3,7",1,1,22,">","#",Cisco-ASR-1000
NYC-CORE-SW-01,192.168.1.2,1,1,"1,3,7",2,1,22,">","#",Cisco-Catalyst-9500
LON-ACCESS-SW-01,192.168.2.10,1,1,"2,3,5",3,2,22,">","#",Cisco-Catalyst-2960X
LON-ACCESS-SW-02,192.168.2.11,1,1,"2,3,5",3,2,22,">","#",Cisco-Catalyst-2960X
SFO-FW-DMZ-01,192.168.10.1,3,4,"7,8",5,3,22,"","",PaloAlto-PA-3020

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

Field	Value	Explanation
device_name	NYC-CORE-RTR-01	Standardized naming: Location-Role-Type-Sequence
ip_address	192.168.1.1	Management interface IP
vendor_id	1	References Cisco vendor (ID 1)
template_id	1	References Cisco-IOS-SSH template (ID 1)
tag_ids	”1,3,7”	Core (1), Production (3), Tier1-Critical (7)
command_group_id	1	Core-Routers command group
credential_id	1	Core-Device-Creds credential set
port	22	Standard SSH port (could be omitted for default)
main_prompt	”>“	User mode prompt
enable_prompt	”#“	Privilege mode prompt
model	Cisco-ASR-1000	Standardized model designation

Note

CSV Formatting Note: When tag_ids 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 vendor_id values exist in rConfig vendor table
• All template_id values exist in rConfig template table
• All command_group_id values exist in rConfig command group table
• All credential_id values exist in rConfig credential table (if used)
• All tag_ids values exist in rConfig tag table

Required field validation:

• Every row has device_name (unique, no spaces, min 3 chars)
• Every row has ip_address (valid IPv4/IPv6 format)
• Every row has vendor_id (numeric, valid reference)
• Every row has template_id (numeric, valid reference)
• Every row has command_group_id (numeric, valid reference)

Optional field validation:

• tag_ids properly formatted (comma-separated, quoted if multiple)
• port values numeric and within valid range (if specified)
• Credentials provided (either credential_id or username/password)
• Prompts configured appropriately for device types

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: Configure Import Options

The import interface provides configuration options affecting import behavior:

Option	Description	Recommendation
Update Existing Devices	Modify devices if name/IP matches	Enable for updates, disable for new-only
Skip Validation Errors	Continue import despite validation failures	Disable—address errors before importing
Send Notification	Email notification on completion	Enable for large imports (100+ devices)
Start Downloads Immediately	Begin configuration downloads post-import	Disable for large imports—schedule separately

Tip

Import Timing Strategy: For imports exceeding 100 devices, disable immediate downloads and schedule configuration retrieval during off-peak hours. This prevents queue congestion and ensures optimal system performance during business hours.

Step 4: Review Validation Results

rConfig performs comprehensive validation before executing the import:

Validation checks performed:

• Required field presence and format
• Prerequisite ID existence (vendors, templates, command groups, credentials, tags)
• Device name uniqueness within import and existing devices
• IP address uniqueness within import and existing devices
• Data format compliance (IP addresses, port numbers, etc.)
• Credential completeness (credential_id OR username/password)

Validation result scenarios:

Validation Success

All Validation Checks Pass

Indication: Green checkmark icon, “Validation Successful” message, device count summary

Actions available:

• Review device list to be imported
• Confirm and proceed with import
• Cancel if final review reveals issues

Recommendation: Review the device summary one final time, then proceed with confidence.

Validation Warnings

Non-Critical Issues Detected

Indication: Yellow warning icon, specific warnings listed, import can proceed

Common warnings:

• Devices will override existing devices (if update mode enabled)
• Optional fields missing (tags, port overrides, etc.)
• Credential references without enable passwords
• Prompt configurations using regex patterns

Recommendation: Review warnings to ensure expected behavior, then proceed if acceptable.

Validation Errors

Critical Issues Prevent Import

Indication: Red error icon, specific errors listed, import blocked

Common errors:

• Missing required fields (device_name, ip_address, vendor_id, template_id, command_group_id)
• Invalid prerequisite IDs (vendor, template, command group, credential, or tag doesn’t exist)
• Duplicate device names within import file
• Duplicate IP addresses within import file
• Invalid data formats (malformed IP addresses, non-numeric port values)
• Missing credentials (no credential_id and no username/password)

Recommendation: Download error report, correct issues in CSV file, re-upload and validate again.

Step 5: Execute Import

Once validation passes (or acceptable warnings reviewed):

1. Click “Confirm Import” button
2. Monitor progress indicator (for large imports)
3. Wait for completion notification
4. Review import summary report

Import progress indicators:

• Devices validated: XXX/YYY
• Devices imported: XXX/YYY
• Errors encountered: XXX
• Estimated time remaining: XX minutes

Step 6: Review Import Summary

Upon completion, rConfig displays comprehensive import results:

Summary report includes:

• Total devices processed
• Successful imports
• Failed imports (with error details)
• Updated devices (if update mode enabled)
• Skipped devices (duplicates if update mode disabled)

Example import summary:

Import Summary
──────────────────────────────────
Total Devices in File:     247
Successfully Imported:     245
Failed to Import:          2
Updated Existing:          0
──────────────────────────────────

Failed Devices:
1. LON-ACCESS-SW-99 - Invalid template_id: 99 (template does not exist)
2. NYC-FW-02 - Duplicate IP address: 192.168.10.1 already exists

Import completed in 3 minutes, 42 seconds

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
5. Check role assignments: If RBAC configured, verify appropriate users see devices

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

Validate RBAC configuration: If role-based access control configured, verify proper access:

1. Test user access with non-admin accounts
2. Verify tag-based role inheritance working correctly
3. Run RBAC data update if inconsistencies found:

   cd /var/www/html/rconfig8/current
   php artisan rconfig:update-rbac-data

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: Validation error “vendor_id XX does not exist” or similar for template_id, command_group_id, credential_id, tag_ids

Cause: CSV file references prerequisite IDs not yet created in rConfig

Resolution:

1. Identify missing prerequisites from validation error messages
2. Create missing prerequisites via rConfig UI or API:
   • Vendors: Settings → Vendors → Add
   • Templates: Settings → Templates → Add
   • Command Groups: Settings → Command Groups → Add
   • Credentials: Settings → Credentials → Add
   • Tags: Settings → Tags → Add
3. Document newly created IDs
4. Update CSV file with correct IDs
5. Re-upload and validate

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

Duplicate Devices

Device Name or IP Already Exists

Symptom: Validation error “device_name XXX already exists” or “ip_address XXX.XXX.XXX.XXX already exists”

Cause: Import file contains duplicate devices, or devices already exist in rConfig

Resolution:

If duplicates within import file:

1. Search CSV file for duplicate device_name values
2. Search CSV file for duplicate ip_address values
3. Remove or correct duplicate entries
4. Re-upload and validate

If devices already exist in rConfig:

Option 1: Enable update mode

• Enable “Update Existing Devices” option in import interface
• Import will modify existing devices with CSV values
• Use for bulk updates to existing device population

Option 2: Remove from import file

• Filter CSV to exclude existing devices
• Import only new devices
• Manually update existing devices if needed

Option 3: Delete existing devices

• Only if existing devices are errors/test data
• Delete conflicting devices from rConfig
• Re-import with corrected data

Prevention: Query existing devices before preparing import to identify conflicts. Use unique, standardized device naming preventing collisions.

Invalid Data Format

Data Format Does Not Meet Requirements

Symptom: Validation errors like “Invalid IP address format”, “Device name contains invalid characters”, “Port must be numeric”

Cause: CSV data doesn’t meet rConfig format requirements

Resolution:

Device name format errors:

• Remove spaces (replace with hyphens or underscores)
• Ensure minimum 3 characters
• Use only alphanumeric, dash, dot, underscore characters
• Example fix: “Core Switch 01” → “CORE-SWITCH-01”

IP address format errors:

• Verify valid IPv4 format (XXX.XXX.XXX.XXX where XXX = 0-255)
• Verify valid IPv6 format if using IPv6
• Remove leading/trailing spaces
• Ensure complete IP address (not partial)

Port number format errors:

• Ensure numeric value only (no text)
• Verify range 1-65535
• Leave empty to use template default (recommended)

Tag ID format errors:

• Ensure comma-separated without spaces: “1,2,3” not “1, 2, 3”
• Enclose in double quotes if multiple: “1,2,3”
• Verify all IDs numeric and exist in tag table

Prevention: Use spreadsheet data validation enforcing format requirements during CSV preparation. Implement validation formulas flagging format errors before export.

Missing Credentials

No Credentials Provided

Symptom: Validation error “Device must have credential_id or username/password”

Cause: Import row missing both credential set reference and inline credentials

Resolution:

Option 1: Add credential_id

• Determine appropriate credential set for device role
• Add credential_id column value referencing existing credential set
• Recommended approach for scalability

Option 2: Add inline credentials

• Add username column with device username
• Add password column with device password
• Add enable_password column if required
• Less secure, use only for unique devices

Prevention: Establish credential strategy before import (credential sets vs inline). Ensure all devices assigned appropriate credentials during CSV preparation.

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/rconfig8/current
  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
• Implement API integration for continuous synchronization at scale

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:

• Configure RBAC during import (assign roles via tags)
• Validate user access post-import ensuring proper restrictions
• Review and approve access requests following defined procedures
• 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 CSV file
• Configure import options (update mode, notifications, etc.)
• Review validation results
• Address any validation errors
• Execute import and monitor progress
• Review import summary report
• Address any failed imports

Post-Import Phase:

• Verify devices appear in device table
• Spot-check device attributes for accuracy
• Test configuration downloads on sample devices
• Address authentication, connectivity, or prompt detection issues
• Schedule bulk configuration downloads if needed
• Configure RBAC if applicable (run update-rbac-data)
• Schedule ongoing configuration backup jobs
• Document import results and lessons learned

Common Import Commands

# Navigate to rConfig directory
cd /var/www/html/rconfig8/current

# Update RBAC data after import with role assignments
php artisan rconfig:update-rbac-data

# Debug specific device download issues (replace 1234 with device ID)
php artisan rconfig:download-device 1234 -d

# Review system logs for import errors
tail -f storage/logs/laravel.log

CSV Template Field Reference

Field	Required	Format	Notes
device_name	Yes	Alphanumeric, _, ., - (no spaces, min 3)	Must be unique
ip_address	Yes	Valid IPv4/IPv6	Must be unique and reachable
vendor_id	Yes	Numeric	Must reference existing vendor
template_id	Yes	Numeric	Must reference existing template
command_group_id	Yes	Numeric	Must reference existing command group
tag_ids	No	Comma-separated numeric (“1,2,3”)	All IDs must exist in tags table
credential_id	No*	Numeric	Must reference existing credential set
username	No*	Text	Required if credential_id not provided
password	No*	Text	Required if credential_id not provided
enable_password	No	Text	Required for privilege escalation if needed
port	No	Numeric (1-65535)	Overrides template default
main_prompt	No	Text or regex	Device CLI prompt for detection
enable_prompt	No	Text or regex	Privilege mode prompt
model	No	Text	Standardized model designation

*Either credential_id OR username/password must be provided

Troubleshooting Quick Reference

Issue	Quick Check	Quick Fix
Validation: Missing prerequisite ID	Verify ID exists in rConfig	Create prerequisite, update CSV with correct ID
Validation: Duplicate device	Check for duplicates in CSV	Remove duplicate or enable update mode
Validation: Invalid format	Check device name, IP format	Apply format corrections in CSV
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:

• Review Devices Documentation for comprehensive device management guidance
• Consult Connection Templates for template configuration best practices
• Explore REST API for programmatic import and continuous synchronization
• Reference Device Prompts for prompt configuration troubleshooting
• Implement RBAC for role-based access control

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 assistance, consult the rConfig Documentation Portal or contact support at [email protected]. Enterprise customers should reach out to their dedicated support contact for migration consultation and import optimization guidance.