Skip to content
rConfig Documentation

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

Section titled “Understanding Device Import Architecture”

The Dependency Model

Section titled “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

Section titled “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.

Section 1: Prerequisites for Device Setup

Section titled “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

Section titled “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

Section titled “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

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

Section titled “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

Section titled “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

Section titled “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

Section titled “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

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

Section titled “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

Section titled “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

Section titled “Import Method Selection”

Manual Device Entry

Section titled “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

Import Method Decision Matrix

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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 |

Import Validation Checklist

Section titled “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

Section titled “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

Section titled “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 |

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:

All Validation Checks Pass

Section titled “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.

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

Section titled “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

Section 5: Post-Import Actions and Optimization

Section titled “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

Section titled “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:
    Terminal window
    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

Section titled “Section 6: Common Issues and Troubleshooting”

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

Import Validation Failures

Section titled “Import Validation Failures”

Prerequisite ID Does Not Exist

Section titled “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.

Post-Import Configuration Issues

Section titled “Post-Import Configuration Issues”

Devices Fail Initial Download - Authentication

Section titled “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

Performance and Scale Issues

Section titled “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

Section titled “Section 7: Best Practices and Recommendations”

Import Planning Best Practices

Section titled “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

Section titled “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

Section titled “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

Section titled “Section 8: Quick Reference”

Import Workflow Checklist

Section titled “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

Section titled “Common Import Commands”
Terminal window
# 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

Section titled “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

Section titled “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

Section titled “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:

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 support@rconfig.com. Enterprise customers should reach out to their dedicated support contact for migration consultation and import optimization guidance.