Devices Management

Device management forms the foundation of rConfig’s configuration management capabilities. Understanding how to effectively add, configure, and organize devices is critical to building a scalable network automation infrastructure. This comprehensive guide covers everything from basic device addition to advanced role-based access controls and troubleshooting strategies.

When to use this

Use this page to choose a device onboarding method, plan the prerequisites that affect device organization, and understand the device table, RBAC model, and troubleshooting paths once devices are in inventory.

Prerequisites

A connection template configured for the device’s platform and protocol (see Connection Templates).
At least one Command Group the device will belong to (see Command Groups).
At least one Tag to assign to the device, since tags are required when adding a device manually.
Valid device credentials, either entered manually or selected from a stored credential set.
device.create permission to add devices.

In network configuration management, the device inventory serves as the single source of truth for your infrastructure. rConfig V8 provides multiple pathways for device onboarding, each designed for specific use cases, from manual entry for small deployments to bulk imports and API integration for enterprise-scale operations. The system’s flexible architecture ensures that whether you’re managing dozens or thousands of devices, you have the tools necessary for efficient operations.

Understanding Device Management in rConfig

Core Concepts

rConfig organizes devices using a hierarchical structure that enables both granular control and broad categorization. This architecture addresses the challenge of managing diverse network infrastructures while maintaining security, operational efficiency, and organizational clarity.

Device Lifecycle: Every device in rConfig follows a defined lifecycle from initial onboarding through active management to eventual decommissioning. Understanding this lifecycle helps organizations implement proper governance:

Onboarding: Device credentials, connection parameters, and organizational attributes are defined
Validation: Initial connection attempts verify accessibility and proper configuration
Active Management: Regular configuration backups and change tracking
Maintenance: Updates to credentials, connection templates, or organizational assignments
Decommissioning: Graceful removal with audit trail preservation

Organizational Hierarchy: Devices are organized through multiple dimensions:

Command Groups: Functional grouping based on device role (Core Switches, Edge Routers, Firewalls)
Vendors: Manufacturer-based organization for template and command consistency
Tags: Flexible, multi-dimensional labeling for cross-cutting concerns (Location, Environment, Criticality)
Roles: Security-based access control determining user visibility and management permissions

This multi-dimensional organization enables powerful filtering, reporting, and automation capabilities while maintaining strict access controls.

Device Addition Methods

rConfig V8 provides five distinct methods for adding devices to your inventory, each optimized for different scenarios and operational requirements:

Manual Device Entry

The manual addition method provides complete control over individual device configuration and is ideal for:

Initial system setup and testing
Adding unique or specialized devices
Situations requiring careful validation of each parameter
Training and familiarization with device structure

When to use: Small-scale deployments (1-10 devices), proof-of-concept environments, or when adding devices with unique configurations that don’t fit bulk import patterns.

Process: Navigate to Devices, click New Device, complete all required fields, and submit. The system immediately validates credentials and initiates an initial configuration download.

Device Prerequisites

Before adding devices to rConfig, establish the foundational configuration elements that define how devices are organized, accessed, and managed. Proper planning of these prerequisites significantly reduces administrative overhead and ensures consistent device management.

Required Configuration Elements

Element	Purpose	Relationship	Configuration Priority
Command Groups	Functional device categorization	One-to-one (device to group)	High - Define first
Commands	Device interrogation instructions	Many-to-many (commands to groups)	High - Define early
Connection Templates	Access method specification	One-to-one (device to template)	Critical - Required
Vendors	Manufacturer organization	One-to-one (device to vendor)	Medium - Useful for filtering
Tags	Flexible multi-dimensional labeling	Many-to-many (devices to tags)	Low - Can add later

Command Groups

Command Groups (formerly Categories) organize devices by functional role within your network infrastructure. This organizational structure determines which command sets execute against which device types.

Design considerations:

Align with network architecture layers (Core, Distribution, Access)
Consider device functionality (Routing, Switching, Security, Wireless)
Plan for future growth and device type expansion
Balance granularity with management complexity

Example structure:

Core Infrastructure
├── Core Routers
├── Core Switches
└── Data Center Fabric

Edge Infrastructure
├── Branch Routers
├── Access Switches
└── Wireless Controllers

Security Infrastructure
├── Firewalls
├── VPN Concentrators
└── IDS/IPS Devices

For detailed command group planning, see Command Groups Documentation.

Commands

Commands define the specific configuration and operational data retrieved from devices. The command library should comprehensively cover both configuration backup and operational visibility requirements.

Essential command categories:

Configuration commands: Full configuration backup (show running-config, show startup-config)
Operational commands: Version, inventory, interface status, routing tables
Security commands: Access lists, authentication configs, encryption status
Diagnostic commands: Logging, error counters, environmental status

Each command associates with one or more Command Groups, enabling targeted execution based on device type. For command creation and management, see Commands Documentation.

Vendors

Vendor designation provides manufacturer-based organization and enables vendor-specific template and command optimization. While not strictly required for operation, vendor classification significantly enhances filtering, reporting, and automation capabilities.

Vendor management benefits:

Template association by manufacturer platform
Command syntax optimization for vendor-specific CLI
Bulk operations on manufacturer-specific device populations
License and support tracking by vendor relationship

Connection Templates

Connection Templates define the authentication method, protocol, and connection parameters for device access. Templates are the most critical prerequisite: devices cannot be added without an assigned template.

Template components:

Protocol: SSH, Telnet, SNMP (v2c/v3)
Authentication: Username/password, SSH keys, SNMP communities
Connection parameters: Port numbers, timeout values, retry logic
Privilege escalation: Enable password handling, privilege mode access

Organizations typically maintain a small library of standard templates (SSH for Cisco IOS, SSH for Juniper Junos, etc.) with variations for different security zones or authentication requirements. For template configuration, see Connection Templates Documentation.

Device Table & Interface

The device table serves as the primary interface for device inventory management, providing comprehensive visibility and control over your entire device population.

Table Features & Capabilities

rConfig device table showing searchable, filterable inventory with status indicators and action menu

Device Table - Primary Inventory View

Search and Filter Capabilities:

Global search: Instantly locate devices by name, IP, model, or any visible attribute
Column filters: Narrow results by vendor, command group, tag, or status
Status filters: Quick access to devices by operational state (up/down/disabled)
Custom views: Save frequently used filter combinations for rapid access

Table Management:

Column customization: Show/hide columns based on operational needs
Pagination: Configurable page size for optimal viewing (25/50/100/500 devices per page)
Sorting: Multi-column sorting for organized device lists
Bulk selection: Select multiple devices for batch operations

Why the Last Backup Failed

From V8.4.2, rConfig records why each device’s last backup failed and shows it in the table. Hover over a device’s status icon to see the reason, when it failed, how many backups in a row have failed and when the last good backup ran. The Last Config column still shows the time of the last good config, with a small red badge such as Auth or Unreachable beside it when the most recent backup failed. The next successful backup clears both.

Badge	Reason starts with	What it usually means
Unreachable	Unreachable	DNS failed, the port is closed or the host didn’t answer
Timeout	Timed out	The device stopped responding during connect or login, or a command never finished
Auth	Authentication failed	Wrong username, password, enable password or SSH key, a TL1 login DENY, or the device returned a login prompt instead of config
Dropped	Connection dropped	The session closed after login
Rejected	Rejected by device	A TL1 command came back DENY, or a script backup met its failure criteria
No output	No output	The device has no command group, or its command group has no commands
Job	Job failure	The backup ran past the queue worker time limit, or never ran

Auth, Unreachable, Timeout, TLS and Dropped make up the Connection/Auth group. To list these devices, open the Status filter and choose Last Backup: Conn/Auth. To list every device whose most recent backup failed, for any reason, choose Last Backup Failed. These differ from Config Failed, which matches any device with a failed backup in its history. The same options are available in the advanced filter.

The same reason appears in the failure notification and email, and on a banner at the top of the device page. The failure notification now opens the device page when you click it.

From V8.4.2, two situations that used to save a bad config now fail the backup instead, and the last good config stays current:

Enable password refused. If the device answers the enable password with a message such as % Bad secrets or % Access denied, or asks for the password again, the backup fails with Authentication failed: Enable password rejected, or the enable prompt was not reached. Before, rConfig carried on without enable mode and saved whatever the device sent back.
A command never finishes. If the device prompt doesn’t come back after a command, and rConfig had already seen the prompt earlier in the session, the backup fails with Timed out: Timed out waiting for the device prompt after "show running-config". Before, the partial output was saved as a good backup. Raise the template’s timeout for slow devices or very large configs. Devices whose template prompt never matches, and MikroTik devices, aren’t affected.

Each device row provides immediate access to common management functions through the action dropdown menu:

Device action menu showing management options including roles, edit, clone, disable, and delete

Device Action Menu - Quick Access Functions

Action	Function	Use Case
Roles	Configure role-based access	Restrict device visibility to specific user roles
Edit	Modify device configuration	Update credentials, templates, or organizational attributes
Clone	Duplicate device settings	Rapidly add similar devices with pre-populated configuration
Disable	Suspend device operations	Temporarily exclude from scheduled jobs without deletion
Delete	Remove device permanently	Decommission devices (requires confirmation, preserves audit trail)

Device Main View

The device detail view provides comprehensive visibility into individual device status, configuration history, and management capabilities.

Device Main View - Detailed Device Management Interface

Key components:

Configuration viewer: Access current and historical configurations with diff capabilities
Manual download: Initiate immediate configuration backup outside scheduled jobs
Activity logs: View connection attempts, download history, and error conditions
Device cloning: Launch clone operation pre-populated with current device settings
Debug tools: Copy debug command to clipboard for troubleshooting connection issues

Operational workflows: The main view supports common operational scenarios such as validating configuration changes, investigating backup failures, and performing ad-hoc configuration retrieval during maintenance windows.

Adding and Editing Devices

Step-by-Step Device Addition

Device Form Field Reference

Complete device configuration form showing all required and optional fields for device addition

Device Configuration Form - Required fields marked with red asterisk

Understanding each field’s purpose and validation requirements ensures successful device onboarding and prevents common configuration errors.

Required Fields

Field	Format Requirements	Notes & Best Practices
Device Name	No whitespace allowed, minimum 5 characters	Use consistent naming convention (e.g., SITE-ROLE-NUMBER). Names should be unique and descriptive for easy identification in logs and reports.
Device IP	Valid IPv4 or IPv6 address	Verify IP reachability before adding device. Use management interface IP for optimal accessibility.
Vendor	Selection from configured vendors	Choose manufacturer to enable vendor-specific optimizations and template associations.
Command Group	Selection from configured command groups	Determines which command sets execute against this device. Must align with device capabilities.
Model	Select from existing or enter new model string	Useful for inventory tracking and template refinement.
Tags	At least one tag	Assign multiple tags for flexible filtering (Location, Environment, Criticality). Plan tag taxonomy for maximum operational value.
Template	Selection from configured templates	Defines connection method, protocol, and authentication approach. Critical for successful device access.

Optional Fields

Field	Purpose	Configuration Guidance
Device Port	Override template default port	Specify when device uses non-standard port (e.g., SSH on 2222 instead of 22). Leave empty to use template default.
Role	Access control assignment	Determines user visibility and management permissions. Leave empty for admin-only access.
SNMP	SNMP Group assignment	Select an SNMP Group to include the device in SNMP polling and trap reception.

Credential Fields

Credential management supports both manual entry and selection from stored credential sets. Organizations managing large device populations benefit significantly from standardized credential sets.

Field	Options	Security Considerations
Username	Manual entry or dropdown selection	Selecting from credential dropdown auto-populates password fields. Credentials are encrypted at rest.
Password	Manual entry or auto-populated	Stored securely using AES-256 encryption. Consider using shared credentials for device role rather than unique per-device.
Enable Password	Optional for privilege escalation	Required only for devices requiring enable mode (Cisco IOS, etc.). Auto-populated when using credential dropdown.
Snippet Credentials	Optional credential set, used only for snippet pushes	New in V8.2.2. Found under Additional Configuration → Separate credentials for snippet pushes. When set, snippet pushes use this set; backups keep using the credentials above. Leave empty to reuse the backup credentials.

Prompt Configuration

Device prompts enable rConfig to detect successful authentication and command completion. Accurate prompt configuration is critical for reliable device interaction.

Prompt Type	Configuration Approach	Examples
Main Prompt	Full specific prompt (preferred) or regex pattern	Full: `router01#`, Regex: `.*[>#]`
Enable Prompt	Privilege mode prompt after escalation	Full: `router01#`, Regex: `.*#`

Prompt configuration strategies:

Exact match (most reliable): Specify complete prompt string including hostname
Partial match: Use regex for dynamic hostnames or standardized prompt formats
Wildcard patterns: Employ when prompt varies by mode or context

For comprehensive prompt configuration guidance including troubleshooting, see Device Prompts Documentation.

Verification Steps

After adding a device, perform these validation steps to ensure proper configuration:

Immediate download verification: Check Queue Manager for successful job completion
Activity log review: Verify no authentication or connection errors in device logs
Configuration validation: Access device main view and confirm configuration retrieval
Scheduled job inclusion: Verify device appears in scheduled download job scope

Role-Based Access Control (RBAC)

rConfig’s device RBAC system enables granular access control, allowing organizations to implement least-privilege principles while maintaining operational efficiency. Understanding the RBAC architecture is essential for multi-team deployments and compliance-driven environments.

Understanding Device RBAC

Role-based access control addresses the challenge of secure multi-team operations where different groups require visibility to different device populations. Rather than providing all users with access to all devices, RBAC enables precise control over device visibility and management permissions.

Core RBAC principles:

Default deny: Users see only devices explicitly assigned to their roles (except admin role)
Role inheritance: Device roles can be inherited from tag associations
Admin override: System admin role maintains universal device access (hardcoded, non-configurable)
Cascading visibility: Role restrictions apply to devices and all related views (commands, templates, vendors)

Configuring Device Roles

Device role assignment interface showing role selection for access control configuration

Device RBAC Configuration - Role Assignment Interface

Role assignment methods:

Direct Device Role Assignment

Assign roles directly to individual devices when granular control is required or when devices don’t fit tag-based categorization.

Process:

Navigate to device edit form
Select roles in the Role field (multi-select enabled)
Save device configuration
Role assignment takes effect immediately

When to use: Unique devices, exceptions to tag-based rules, temporary access grants, devices in transition between roles.

RBAC Hierarchy and Precedence

The RBAC system follows a defined hierarchy that determines effective permissions when multiple role sources exist:

System Admin Role (Hardcoded)
    ↓ [Universal Access - Cannot be Restricted]
Tag-Based Role Assignment
    ↓ [Inherited by all devices with tag]
Direct Device Role Assignment
    ↓ [Explicit device-specific access]
No Role Assignment
    ↓ [Device invisible to non-admin users]

Key behaviors:

Additive permissions: Multiple role assignments are cumulative (union of all assigned roles)
No role = admin only: Devices without any role assignment are visible only to admin users
Tag changes propagate immediately: Adding or removing tags instantly updates role-based visibility
Cross-view restrictions: Role limitations apply to devices, command groups, commands, templates, and vendors

RBAC Implementation Best Practices

Planning considerations:

Role design: Align roles with organizational structure (teams, regions, functions)
Tag taxonomy: Design tag structure to support role-based access patterns
Exception handling: Plan for devices requiring cross-team visibility
Audit requirements: Ensure role assignments support compliance reporting needs

Common RBAC patterns:

Geographic isolation: Regional teams see only local devices via tag-based regional roles
Functional separation: Network team roles grant access to infrastructure devices; security team roles grant access to security devices
Tiered support: Level 1 support limited to access layer; Level 2 accesses distribution; Level 3 accesses all tiers
Vendor specialization: Cisco specialists see Cisco devices; Juniper specialists see Juniper devices

Scaling RBAC to enterprise deployments:

For organizations managing 1,000+ devices across multiple teams, consider these architectural approaches:

Implement tag-based roles as primary access control mechanism
Reserve direct device assignment for exceptions only (reduces administrative overhead by 90%+)
Establish clear governance for tag creation and role assignment
Document role-to-team mappings for audit and onboarding purposes
Regular access review cycles to validate role assignments remain appropriate

Troubleshooting Device Management

Common Device Addition Issues

Understanding typical failure scenarios and their resolutions accelerates troubleshooting and reduces downtime during device onboarding.

Authentication and Connectivity Issues

Symptom: Device addition completes but initial download job fails with authentication or timeout errors.

Common causes and resolutions:

Issue	Diagnostic Steps	Resolution
Invalid credentials	Review activity logs for “Authentication failed” errors	Verify username/password accuracy; test credentials via manual SSH/Telnet session
Network unreachability	Ping device IP from rConfig server, check firewall rules	Verify network connectivity; add rConfig server IP to device management ACLs
Incorrect port	Verify service listening on expected port (netstat, telnet)	Update device port field or template configuration to match actual service port
Prompt mismatch	Review logs for timeout during prompt detection	Correct main/enable prompt fields to match actual device prompt strings
Enable password required	Connection succeeds but privilege escalation fails	Add enable password to device configuration if privilege mode required

Debug workflow:

Copy debug command from device main view
Execute on rConfig server command line:
Terminal window
```
cd /var/www/html/rconfig8/current
php artisan rconfig:download-device 1234 -d
```
(Replace 1234 with actual device ID)
Review detailed connection trace for specific failure point
Apply appropriate resolution based on failure stage (connection, authentication, privilege escalation, prompt detection)

Device Form Validation Errors

Symptom: Form submission fails with validation errors or unexpected behavior after saving.

Resolution guide:

Error Message	Cause	Fix
“Device name must be at least 3 characters”	Name too short	Provide descriptive name meeting minimum length
“Device name contains invalid characters”	Spaces or special characters in name	Remove spaces; use only alphanumeric, dash, dot, underscore
“IP address format invalid”	Malformed IP address	Verify valid IPv4 or IPv6 format
“Template is required”	No connection template selected	Select appropriate connection template for device type
“Command group is required”	No command group selected	Assign device to appropriate command group

Form completion checklist:

Device name follows naming convention (no spaces, min 3 chars)
IP address is valid and reachable from rConfig server
Vendor selected from dropdown
Command group assigned based on device function
Connection template appropriate for device platform
Credentials validated (test SSH/Telnet access manually)
Prompts configured accurately (exact match or regex pattern)

Role-Based Access Problems

Symptom: Users report missing devices or inability to access devices they should manage.

Diagnostic approach:

Verify role assignment:
- Check device role field in device edit form
- Confirm user assigned to expected role in user management
- Review tag-based role inheritance if applicable
Check RBAC hierarchy:
- Confirm device has at least one role assigned (or should be admin-only)
- Verify tag-based roles if device access should inherit from tags
- Ensure no conflicting role restrictions
Validate role propagation:
- Run RBAC update command to ensure role assignments current:
  Terminal window
```
cd /var/www/html/rconfig8/current
php artisan rconfig:update-rbac-data
```
- Verify user session refreshed (logout/login) after role changes

Common RBAC scenarios:

Device invisible to non-admin: Device has no roles assigned. Add appropriate role via device edit or tag assignment.
Tag changes not reflected: Role inheritance may require propagation. Run update-rbac-data command.
Cross-view restrictions: User cannot see command groups, commands, or templates. Verify devices with those associations have user’s role.

Advanced Troubleshooting Commands

For persistent issues requiring deeper investigation, utilize these diagnostic commands:

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

# Update all device RBAC data to ensure consistency
php artisan rconfig:update-rbac-data

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

# Check queue worker status for job processing issues
php artisan queue:work --once --verbose

# Review system logs for detailed error information
tail -f storage/logs/laravel.log

Best Practices for Device Management

Organizational Strategy

Device naming conventions: Establish consistent naming that encodes critical device information while maintaining uniqueness:

Include site/location identifier
Add device role or function
Append sequence number or rack position
Examples: NYC-CORE-RTR-01, LON-ACCESS-SW-FL3-12, SFO-FW-DMZ-01

Credential management:

Create role-based credential sets rather than per-device credentials
Implement regular credential rotation schedules (quarterly minimum)
Use separate credentials for different security zones or compliance domains
Maintain emergency “break-glass” credentials with strict audit requirements

Command group design:

Align with network architecture layers and device functions
Create granular groups for specialized device types
Plan for expansion, avoiding overly broad or narrow categorization
Document command group purpose and intended device types

Tag taxonomy:

Design multi-dimensional tag structure (geography, environment, criticality, function)
Establish tag naming conventions to prevent proliferation
Document tag meanings and appropriate usage
Regularly audit tag assignments to prevent tag sprawl

Operational Efficiency

Bulk operations: Leverage bulk capabilities for efficiency at scale:

Use CSV import for initial population or major inventory updates (50+ devices)
Employ API integration for continuous synchronization with authoritative sources
Utilize device cloning for rapid standardized deployments
Implement tag-based bulk operations (disable all devices with specific tag)

Template standardization: Maintain a focused template library:

Create standard templates for common platform/protocol combinations
Avoid template proliferation: combine similar templates when possible
Document template purpose and intended device types
Version template changes and test against representative devices

RBAC governance:

Implement tag-based role assignment for 90%+ of devices
Reserve direct device assignment for genuine exceptions
Document role-to-team mappings and maintain in configuration management
Regular access reviews to validate role assignments remain appropriate (quarterly)
Establish clear procedures for access requests and approvals

Security Considerations

Credential security:

Never store credentials in unencrypted external systems
Use rConfig’s credential dropdown feature to minimize credential exposure during device addition
Implement credential rotation aligned with organizational security policy
Audit credential usage through activity logs

Access control:

Apply principle of least privilege via RBAC role assignments
Regularly review user-to-role mappings for appropriateness
Implement separation of duties for critical infrastructure devices
Audit device access patterns through activity logs and compliance reports

Network security:

Restrict rConfig server access to management networks only
Implement firewall rules limiting rConfig to required device management protocols
Use encrypted protocols (SSH) instead of plaintext (Telnet) wherever possible
Isolate rConfig in dedicated management VLAN with strict access controls

Compliance requirements:

Maintain audit trails for all device configuration changes
Implement RBAC aligned with compliance mandates (PCI-DSS, HIPAA, SOX)
Establish retention policies for historical configurations
Document device access patterns for audit review

Scalability and Performance

Job queue optimization: Ensure efficient job processing for large device populations:

Run multiple queue workers for parallel job processing
Prioritize critical devices using queue priorities
Monitor queue depth and worker performance metrics
Scale queue workers based on job volume (1 worker per 500 devices recommended)

API rate limiting: When using API integration for continuous synchronization:

Implement exponential backoff for API retry logic
Batch API calls to minimize overhead (50-100 devices per request)
Schedule bulk synchronization during off-peak hours
Monitor API rate limits and adjust synchronization frequency accordingly

Advanced Features and Techniques

Automated Device Discovery

While rConfig does not include built-in network discovery, organizations can implement automated device discovery through integration workflows:

Discovery workflow architecture:

External discovery tool identifies network devices (network scanners, SNMP discovery, cloud inventory APIs)
Discovery results formatted as CSV or JSON payload
Automated process imports devices via CSV import or REST API
Initial configuration download validates device accessibility
Failed devices flagged for credential or connectivity remediation

Integration examples:

SNMP-based discovery: Use network management platform to discover SNMP-enabled devices, export inventory, import to rConfig
Cloud inventory: Query cloud provider APIs (AWS EC2, Azure VM) for virtual network appliances, sync via API
CMDB synchronization: Scheduled job exports network devices from CMDB, imports to rConfig maintaining single source of truth

Dynamic Device Grouping

Beyond static command groups and tags, implement dynamic grouping for operational flexibility:

Use cases:

Maintenance windows: Create temporary “Under-Maintenance” tag, assign to devices, exclude from scheduled jobs
Phased rollouts: Tag devices by rollout phase, target configuration changes incrementally
Incident response: Rapidly identify and group affected devices using tag combinations
Audit scoping: Dynamic tag-based queries for compliance reporting (all PCI devices in production)

Implementation approach: Leverage tag multi-select and advanced search to create virtual device groups without rigid hierarchical constraints.

Comprehensive device management requires understanding related rConfig capabilities:

Device Prompts: Configure accurate prompt detection for reliable device interaction
Device Import Workbook: Bulk device onboarding via CSV files
Connection Templates: Configure connection methods, protocols, and authentication
Command Groups: Organize devices by functional role
Commands: Define configuration and operational data retrieval
REST API: Programmatic device management and integration
Queue Manager: Monitor and troubleshoot download jobs
Application Log: Audit device access and configuration changes
RBAC Administration: Configure roles and access control policies

Quick Reference

Device Addition Methods Comparison

Method	Best For	Scale	Complexity	Automation
Manual	Initial setup, unique devices	1-10 devices	Low	None
Clone	Similar devices, standardized deployments	10-50 devices	Low	Minimal
CSV Import	Bulk onboarding, migrations	50-5,000 devices	Medium	Partial
REST API	Continuous sync, integration	Unlimited	High	Full
Third-Party	Existing tool integration	Unlimited	High	Full

Common Commands Quick Reference

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

# Update device RBAC data for consistency
php artisan rconfig:update-rbac-data

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

# Monitor queue worker status
php artisan queue:work --once --verbose

# View recent system logs
tail -f storage/logs/laravel.log

Device Form Field Quick Reference

Field	Required	Format	Notes
Device Name	Yes	No whitespace, min 5 chars	Use consistent naming convention
Device IP	Yes	Valid IPv4/IPv6	Must be reachable from rConfig server
Device Port	No	Numeric	Override template port if needed
Vendor	Yes	Dropdown selection	For organization and filtering
Command Group	Yes	Dropdown selection	Determines command execution
Model	Yes	Text or dropdown	Useful for inventory tracking
Tags	Yes	Multi-select	At least one tag required
Role	No	Multi-select	Controls access visibility
SNMP	No	SNMP Group selection	Include in SNMP monitoring
Username	Yes	Text or credential dropdown	Credential dropdown auto-populates password
Password	Yes	Password or auto-populated	Encrypted at rest
Enable Password	No	Password or auto-populated	Required for privilege escalation
Template	Yes	Dropdown selection	Defines connection method
Main Prompt	Yes	Exact string or regex	Critical for connection success
Enable Prompt	No	Exact string or regex	For privilege mode detection

RBAC Hierarchy Quick Reference

Access Level Hierarchy (Top = Highest Privilege):

1. System Admin Role
   └─ Universal access to all devices (hardcoded, non-configurable)

2. Tag-Based Role Assignment
   └─ Inherited by all devices with matching tag
   └─ Dynamic (changes with tag addition/removal)

3. Direct Device Role Assignment
   └─ Explicit device-specific access
   └─ Overrides for special cases

4. No Role Assignment
   └─ Device visible to admin users only
   └─ Hidden from all other roles

Troubleshooting Decision Tree

Device Connection Fails
│
├─ Authentication Error?
│  ├─ Verify credentials manually (SSH/Telnet)
│  ├─ Check username/password accuracy
│  └─ Confirm enable password if required
│
├─ Timeout/Network Unreachable?
│  ├─ Verify IP reachability (ping from rConfig server)
│  ├─ Check firewall rules
│  └─ Confirm correct port configuration
│
├─ Prompt Detection Fails?
│  ├─ Review device logs for actual prompt string
│  ├─ Update main/enable prompt fields
│  └─ Test with exact match before using regex
│
└─ Configuration Download Fails?
   ├─ Verify command group has appropriate commands
   ├─ Check device supports command syntax
   └─ Review activity logs for specific error details

What’s next

Connection Templates - Configure the protocol and authentication a device uses to connect
Device Prompts - Get reliable prompt detection for consistent backups
Device Import Workbook - Onboard devices in bulk via CSV

Devices Management