Skip to content
rConfig Documentation

Basic Connectivity Verification

Basic Connectivity Verification

Section titled “Basic Connectivity Verification”

Before troubleshooting rConfig-specific issues, confirm the rConfig server can reach the device on the network and the management protocol is accepting connections.

When to use this

Section titled “When to use this”

Use this guide as your first step whenever rConfig fails to download a device configuration. Network connectivity problems are the most common root cause of backup failures, so eliminating them early saves time before investigating credentials, prompts, or protocol settings.

Prerequisites

Section titled “Prerequisites”
  • rConfig installed and the application running
  • The target device IP address and the management protocol it uses (SSH, Telnet, or SNMP)
  • Shell access to the rConfig server to run diagnostic commands

Network Layer Testing

Section titled “Network Layer Testing”

Run all of the following commands from the rConfig server itself, not from a workstation. The network path from a workstation may differ from the path rConfig actually uses.

  1. Ping the device (if ICMP is permitted):

    Terminal window
    ping -c 4 192.168.1.1

    A successful ping confirms the device is powered on, routing exists between the rConfig server and the device, and the firewall permits ICMP.

  2. Test port connectivity:

    Test SSH (port 22):

    Terminal window
    nc -zv 192.168.1.1 22

    Test Telnet (port 23):

    Terminal window
    nc -zv 192.168.1.1 23

    Test a custom SSH port (e.g., 2222):

    Terminal window
    nc -zv 192.168.1.1 2222

    “Connection succeeded” confirms the service is listening. A refused connection means the service is not running, a firewall is blocking the port, or the wrong port is configured in rConfig.

  3. Trace the route:

    Terminal window
    traceroute 192.168.1.1
    mtr 192.168.1.1

    Trace output shows where packets stop if connectivity fails. Look for timeouts at specific hops, firewall ACLs dropping traffic, or asymmetric routing causing return traffic loss.

If network connectivity fails, check these areas:

  • Verify the device management interface has an IP address and is administratively up
  • Review firewall rules on all devices between the rConfig server and the target device
  • Confirm routing tables include the device management networks
  • Check VLANs and VRFs are configured correctly for management traffic

Service Availability Testing

Section titled “Service Availability Testing”

Once network connectivity is confirmed, verify the management protocol service is accessible.

  1. Test SSH:

    Terminal window
    ssh admin@192.168.1.1

    A successful test returns an SSH version banner, host key fingerprint, and an authentication prompt. Failures may indicate the SSH service is not enabled, an SSH version mismatch, host key problems, or cipher negotiation failures.

  2. Test Telnet:

    Terminal window
    telnet 192.168.1.1

    A successful test returns a login prompt or banner. Failures indicate Telnet is disabled, VTY lines are not configured, or access-class restrictions are blocking the connection.

  3. Test SNMP (for SNMP-managed devices):

    Terminal window
    snmpwalk -v 2c -c public 192.168.1.1 system

    A successful test returns system information. Failures indicate SNMP is not enabled, an incorrect community string, SNMP ACLs blocking access, or the wrong SNMP version.

What’s next

Section titled “What’s next”