Device Import Workbook

Prerequisites

• rConfig v8 installed and accessible.
• Access to System Settings → Data Management → Import/ Export.
• Vendor, template, command group, and credential data ready before importing devices (see Section 1 below).

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.

New in V8.2.2

• Snippet credentials column. The import accepts an optional device_snippet_cred_id column. Set it to a credential set ID to give the device a separate credential set used only for snippet pushes, or leave it 0 (the default) to reuse the device’s backup credentials. The ID is validated on import only when it is non-zero.
• Credential set visibility by role. Credential sets can be restricted to specific roles. A set with no roles stays visible to everyone, so existing imports are unaffected. Assign roles per set under System Settings → Security & Access → Device Credentials, not in the CSV. See Roles and Permissions.

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 the import template from System Settings → Data Management → Import/ Export
2. Populate template with device data and prerequisite IDs
3. Validate data completeness and accuracy
4. Upload CSV file through import interface
5. Review validation results and address errors
6. Confirm import and monitor job progress

CSV template structure:

device_name,device_ip,device_username,device_password,device_enable_password,device_main_prompt,device_enable_prompt,device_category_id,device_template,device_model,device_vendor,device_tag,device_default_creds_on,device_cred_id,device_snippet_cred_id,agent_id,device_port_override,snmp_polling_group_id,device_roles
CoreSwitch01,192.168.1.1,,,,"CoreSwitch01#","CoreSwitch01>",1,1,Cisco-Catalyst-3850,1,"1,2",1,1,0,,,,"2,3"
AccessSwitch01,192.168.2.1,,,,"AccessSwitch01#","AccessSwitch01>",2,1,Cisco-Catalyst-2960,1,"2,5",1,2,0,,2222,3,

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",
  "device_ip": "192.168.1.1",
  "device_vendor": 1,
  "device_template": 1,
  "device_category_id": 1,
  "device_tags": [1, 2],
  "device_default_creds_on": 1,
  "device_cred_id": 1,
  "device_port_override": 22,
  "device_main_prompt": "CoreSwitch01#",
  "device_enable_prompt": "CoreSwitch01>",
  "device_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 ships an XLSX import template with every column the importer reads. You can upload it as XLSX or save it as CSV first. Column names must match the template exactly. The importer ignores any column it doesn’t recognise, so a misspelled header is silently skipped rather than reported.

Obtaining the template:

1. Navigate to System Settings → Data Management → Import/ Export
2. Click Download Template in step 1 of the Device Import Wizard
3. Save the file to your working directory
4. Fill in one row per device under the header row

The template is served by your rConfig server, so it always matches the columns your installed version accepts. Templates downloaded before V8.4.0 are missing device_snippet_cred_id, agent_id, device_port_override and snmp_polling_group_id. Templates downloaded before V8.4.1 are also missing device_roles. Download a fresh copy, or add those headers to your existing file.

Template structure overview:

Required columns (a blank cell in any of these fails the row with Blank Fields):

• device_name: Unique device name, no spaces
• device_ip: IPv4 or IPv6 address, or a hostname
• device_vendor: Vendor ID
• device_template: Connection template ID
• device_category_id: Command group ID
• device_tag: Tag ID, or comma-separated tag IDs (e.g., “1,2,5”)
• device_model: Model name (free text)
• device_main_prompt: Device CLI prompt
• device_enable_prompt: Privilege mode prompt. Use placeholder text if the device has no enable mode.

Credential columns:

• device_default_creds_on: 1 to use a credential set, 0 to use the inline username and password columns
• device_cred_id: Credential set ID when device_default_creds_on is 1, otherwise 0
• device_username, device_password, device_enable_password: Inline credentials, used when device_default_creds_on is 0
• device_snippet_cred_id: Optional separate credential set for snippet pushes. Leave 0 to reuse the backup credentials.

Optional columns (leave blank to skip):

• device_port_override: Connection port, 1-65535. Leave blank to use the port set in the device’s connection template.
• snmp_polling_group_id: SNMP polling group ID. Leave blank or 0 for no SNMP polling.
• agent_id: Vector agent ID. Leave blank to use the default agent.
• device_roles: Role IDs that can see the device, as one ID or a comma-separated list (e.g., “2,3”). The Admin role (1) is always added. Leave blank for Admin only.

New in V8.4.0

device_port_override and snmp_polling_group_id set the Device Port and SNMP fields you see on the device form. Earlier versions ignored these columns even when you added them by hand. Find SNMP polling group IDs under Inventory → SNMP Properties → SNMP Groups (see SNMP polling).

Data Preparation Workflow

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

Step 1: Extract Legacy Data

Export device inventory from legacy system to spreadsheet format:

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

Step 2: Create Prerequisite Mapping Tables

Build reference tables mapping legacy values to rConfig IDs:

Vendor mapping example:

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

Template mapping example:

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

Command group mapping example:

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

Step 3: Transform and Standardize Data

Apply transformations to align legacy data with rConfig standards:

Device name standardization:

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

IP address validation:

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

Model standardization:

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

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

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

Step 4: Populate Import Template

Map transformed data to rConfig template columns:

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

Step 5: Validate Import Data

Perform comprehensive validation before import:

Required field validation:

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

ID existence validation:

• Cross-reference device_vendor against vendor table
• Cross-reference device_template against template table
• Cross-reference device_category_id against command group table
• Validate device_tag IDs exist (split comma-separated values and check each)
• Cross-reference snmp_polling_group_id against SNMP polling groups (if used)
• Cross-reference device_roles against the Roles page (if used)

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 (same columns, in the same order, as the downloaded template):

device_name,device_ip,device_username,device_password,device_enable_password,device_main_prompt,device_enable_prompt,device_category_id,device_template,device_model,device_vendor,device_tag,device_default_creds_on,device_cred_id,device_snippet_cred_id,agent_id,device_port_override,snmp_polling_group_id,device_roles
NYC-CORE-RTR-01,192.168.1.1,,,,"NYC-CORE-RTR-01#","NYC-CORE-RTR-01>",1,1,Cisco-ASR-1000,1,"1,3,7",1,1,0,,,2,"2,3"
NYC-CORE-SW-01,192.168.1.2,,,,"NYC-CORE-SW-01#","NYC-CORE-SW-01>",2,1,Cisco-Catalyst-9500,1,"1,3,7",1,1,0,,,2,"2,3"
LON-ACCESS-SW-01,192.168.2.10,,,,"LON-ACCESS-SW-01#","LON-ACCESS-SW-01>",3,1,Cisco-Catalyst-2960X,1,"2,3,5",1,2,0,,,,2
LON-ACCESS-SW-02,192.168.2.11,,,,"LON-ACCESS-SW-02#","LON-ACCESS-SW-02>",3,1,Cisco-Catalyst-2960X,1,"2,3,5",1,2,0,,,,2
SFO-FW-DMZ-01,192.168.10.1,fwadmin,secret,,"SFO-FW-DMZ-01>","SFO-FW-DMZ-01>",5,4,PaloAlto-PA-3020,3,"7,8",0,0,0,,2222,,

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

Field	Value	Explanation
device_name	NYC-CORE-RTR-01	Standardized naming: Location-Role-Type-Sequence
device_ip	192.168.1.1	Management interface IP
device_username, device_password, device_enable_password	(blank)	Not used, because this row uses a credential set
device_main_prompt	“NYC-CORE-RTR-01#”	Privileged exec prompt
device_enable_prompt	“NYC-CORE-RTR-01>”	User mode prompt, before enable
device_category_id	1	Core-Routers command group
device_template	1	Cisco-IOS-SSH connection template (ID 1)
device_model	Cisco-ASR-1000	Standardized model designation
device_vendor	1	Cisco vendor (ID 1)
device_tag	“1,3,7”	Core (1), Production (3), Tier1-Critical (7)
device_default_creds_on	1	Use the credential set in device_cred_id
device_cred_id	1	Core-Device-Creds credential set
device_snippet_cred_id	0	Snippet pushes reuse the backup credentials
agent_id	(blank)	Default agent
device_port_override	(blank)	Use the connection template’s port
snmp_polling_group_id	2	Poll this device with SNMP polling group 2
device_roles	“2,3”	Users in roles 2 and 3 can see the device. Admin (1) is added automatically

The SFO-FW-DMZ-01 row shows the other options: inline credentials (device_default_creds_on set to 0) and a non-standard SSH port of 2222. It also leaves device_roles blank, so only Admin users see it until roles are added.

Note

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

Import Validation Checklist

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

Prerequisite validation:

• All device_vendor values exist in rConfig vendor table
• All device_template values exist in rConfig template table
• All device_category_id values exist in rConfig command group table
• All device_cred_id and device_snippet_cred_id values exist in rConfig credential table (if used)
• All device_tag values exist in rConfig tag table
• All snmp_polling_group_id values exist as SNMP polling groups (if used)
• All device_roles values exist as roles (if used)

Required field validation:

• Every row has device_name (unique, no spaces, min 3 chars)
• Every row has device_ip (valid IPv4/IPv6 format)
• Every row has device_vendor (numeric, valid reference)
• Every row has device_template (numeric, valid reference)
• Every row has device_category_id (numeric, valid reference)
• Every row has device_tag (numeric, or comma-separated numeric)
• Every row has device_model, device_main_prompt and device_enable_prompt

Optional field validation:

• device_tag and device_roles properly formatted (comma-separated, quoted if multiple)
• device_port_override values numeric and within 1-65535 (if specified)
• Credentials provided (device_default_creds_on 1 with device_cred_id, or 0 with 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 System Settings → Data Management → 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 (device_cred_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, device_ip, device_vendor, device_template, device_category_id, device_tag, device_model, prompts)
• 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 device_cred_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. Import Error LON-ACCESS-SW-99: Invalid Template ID
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

The importer checks each row on its own. A bad row is skipped with an Import Error <device_name>: <reason> message, and the other rows still import. See Import error messages for the full list.

Missing Prerequisites

Prerequisite ID Does Not Exist

Symptom: Invalid Vendor ID, Invalid Template ID, Invalid Category ID, Invalid Tag ID, Invalid Credentials ID, Invalid SNMP Polling Group ID, or Invalid Role ID

Cause: The row references an ID that hasn’t been created in rConfig yet, or a typo in the ID.

Resolution:

1. Note which column the error names
2. Create the missing item in rConfig, or look up the correct ID in the relevant table (Vendors, Templates, Command Groups, Tags, Device Credentials, SNMP Groups, Roles)
3. Fix the ID in your file
4. Re-upload only the rows that failed, so the rows that already imported aren’t added twice

Prevention: Create every prerequisite before preparing the import file, and keep an ID mapping table next to it.

Blank Fields

A Required Column Is Empty

Symptom: Blank Fields

Cause: One of device_name, device_ip, device_vendor, device_template, device_category_id, device_tag, device_model, device_main_prompt or device_enable_prompt is empty for that row.

Resolution: Fill the empty cell. If the device has no enable mode, put placeholder text in device_enable_prompt rather than leaving it blank.

Duplicate Devices

Device Already Exists

The importer doesn’t check for duplicates. A row whose name or IP already exists in rConfig is imported as a second device, and re-uploading a file adds every row again.

Resolution:

• Before uploading, compare your file against an export of existing devices and remove rows that are already in rConfig
• Search the file for duplicate device_name and device_ip values
• If a re-upload created duplicates, delete the extra devices from the Devices table

Invalid Data Format

Data Format Does Not Meet Requirements

Device names: characters other than letters, numbers, _, . and - are stripped on import rather than rejected. “Core Switch 01” imports as “CoreSwitch01”. Replace spaces with hyphens before importing if you want them kept as separators.

IP addresses: not validated on import. Check them in the spreadsheet first, because a typo only shows up later as a failed backup.

Port numbers: Invalid Device Port means device_port_override isn’t a whole number from 1 to 65535. Leave it blank to use the connection template’s port.

Tag IDs: use comma-separated IDs without spaces (“1,2,3”, not “1, 2, 3”) and quote the value in CSV files.

Prevention: Add spreadsheet data validation for these columns before saving the file.

Credentials

Credentials Not Applied

Symptom: Invalid Credentials ID, or the device imports but backups fail with authentication errors

Cause: device_default_creds_on is 1 with a device_cred_id that doesn’t exist, or device_default_creds_on is 0 and the inline username and password are blank. The importer doesn’t reject rows with no credentials at all.

Resolution:

Option 1: Use a credential set (recommended)

• Set device_default_creds_on to 1
• Set device_cred_id to an existing credential set ID

Option 2: Use inline credentials

• Set device_default_creds_on to 0 and device_cred_id to 0
• Fill device_username, device_password and, if needed, device_enable_password

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 with the device_roles column)
• 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 System Settings → Data Management → 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	Letters, numbers, _, ., - (no spaces)	Other characters are stripped on import
device_ip	Yes	IPv4, IPv6 or hostname	Management address
device_username	No*	Text	Used when device_default_creds_on is 0
device_password	No*	Text	Used when device_default_creds_on is 0
device_enable_password	No	Text	Used when device_default_creds_on is 0
device_main_prompt	Yes	Text	Device CLI prompt
device_enable_prompt	Yes	Text	Privilege mode prompt. Placeholder text if unused.
device_category_id	Yes	Numeric	Must reference existing command group
device_template	Yes	Numeric	Must reference existing connection template
device_model	Yes	Text	Standardized model designation
device_vendor	Yes	Numeric	Must reference existing vendor
device_tag	Yes	Numeric, or comma-separated (“1,2,3”)	Tag IDs must exist
device_default_creds_on	No	0 or 1	Defaults to 0 when the column is missing
device_cred_id	No*	Numeric	Must reference existing credential set when device_default_creds_on is 1. Use 0 otherwise.
device_snippet_cred_id	No	Numeric	Credential set for snippet pushes. 0 or blank reuses backup credentials.
agent_id	No	Numeric	Vector agent ID. Blank uses the default agent.
device_port_override	No	Numeric (1-65535)	Blank uses the connection template’s port
snmp_polling_group_id	No	Numeric	Must reference existing SNMP polling group. Blank or 0 for none.
device_roles	No	Numeric, or comma-separated (“2,3”)	Role IDs that can see the device. Admin (1) is always added. Blank gives Admin only.

*Set device_default_creds_on to 1 with a device_cred_id, or to 0 with device_username and device_password.

Import error messages

Rows that fail validation are skipped and the rest of the file still imports. Each skipped row is listed after the upload and in the activity log as Import Error <device_name>: <reason>.

Reason	Cause
Blank Fields	A required column is empty
Invalid Credentials ID	device_default_creds_on is 1 and device_cred_id doesn’t exist
Invalid Snippet Credentials ID	device_snippet_cred_id is non-zero and doesn’t exist
Invalid Category ID	device_category_id doesn’t exist
Invalid Vendor ID	device_vendor doesn’t exist
Invalid Template ID	device_template doesn’t exist
Invalid Tag ID	None of the IDs in device_tag exist
Invalid Device Port	device_port_override isn’t a whole number from 1 to 65535
Invalid SNMP Polling Group ID	snmp_polling_group_id is non-zero and doesn’t exist, or isn’t a number
Invalid Agent ID	agent_id doesn’t exist (Vector installs only)
Invalid Role ID	An ID in device_roles doesn’t exist, or the value isn’t whole numbers separated by commas

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

What’s next

• Connection Templates - Template configuration best practices
• Device Prompts - Prompt configuration troubleshooting
• REST API - Programmatic import and continuous synchronization
• RBAC - Role-based access control for credential visibility