This article explains how to copy a customer’s Confd CDB files onto an isolated test VM, restart services, and prevent accidental internet egress from the customer’s Transport VRF.

Files covered: O.cdb, A.cdb, C.cdb (and any additional *.cdb in the same directory).

After the customer database is loaded, the admin/versa password, console behavior, and Versa login may follow the customer’s CDB and no longer match your lab credentials. A pre-created Linux user gives you a path back to the OS to fix or roll back files.

Steps

• Create a dedicated local user (e.g., labtest) with a strong password.
• Confirm SSH and console login work as that user before replacing CDB files.

Example (RHEL / CentOS-style)

sudo useradd -m -s /bin/bash -G versa,sudo,versa_priv labtest

sudo passwd labtest

• VOS cdb files obtained from the customer's appliance or techsupport bundle
• Test VM is lab-only with no production traffic. Prefer no default route on transport interfaces until routing is verified.
• Existing CDB files on the test VM are backed up before they are replaced (see Section 4).

On a Live Versa Appliance

Path

/opt/versa/confd/var/confd/cdb/

ls -lth *.cdb

Typical files: O.cdb, A.cdb, and C.cdb (sizes and dates vary).

Inside a Techsupport Bundle

Customer CDBs are often included in techsupport archives. After extraction, locate the same relative Confd CDB path documented in the bundle. Use the same *.cdb set you would use from a live system so the test VM receives a consistent dataset.

Transfer to the Test VM

SCP

scp admin@<source-host>:/var/tmp/*.cdb admin@<test-vm>:/var/tmp/

Verify Integrity (Recommended)

Compare file sizes or checksums on both ends before proceeding:

ls -lth /var/tmp/*.cdb

md5sum /var/tmp/*.cdb

Step 1 — Back Up Existing CDB

DEST=/home/admin/cdb-backup-$(date +%Y%m%d-%H%M%S) && mkdir -p "$DEST" && sudo cp -a /opt/versa/confd/var/confd/cdb/*.cdb "$DEST/"

Step 2 — Install the Customer CDB Files

sudo cp /var/tmp/O.cdb /var/tmp/A.cdb /var/tmp/C.cdb /opt/versa/confd/var/confd/cdb/ 

Verify ownership matches what the Versa software expects (typically root:root): 

ls -l /opt/versa/confd/var/confd/cdb/

Step 3 — Restart Versa Services

vsh restart

Wait until vsh and related processes are stable (no repeated crash loops). Use your normal health checks such as vsh status and service logs per your Versa release documentation.

Check for a Default Route

In configuration mode, inspect static routes for the transport routing instance (replace INET-Transport-VR if your customer uses a different VRF name):

Look for any 0.0.0.0/0 (IPv4) or ::/0 (IPv6) static route in the transport instance.

show route routing-instances <>-Transport-VR

Remove the Default Route

If a static default exists, it must be removed. 

Example: 

delete routing-instances INET-Transport-VR routing-options static route 0.0.0.0/0 <gateway-ip> none tag 0

Note: Replace <gateway-ip> with the actual gateway from the existing route.

Avoid putting WAN/VNI interfaces on publicly routable networks.

Eg: Bad Lab Example

Internet
|
[ Public IP directly on WAN/VNI ]
|
Versa Device

Eg: Recommended Lab Example

Internet
|
Firewall / NAT
|
Private WAN/VNI IP (Versa)

Verify Isolation

• No unintended 0.0.0.0/0 or ::/0 remains in Transport-VR unless lab internet is explicitly required.
• From a test session in that VRF, confirm no reachability to public addresses, or verify that uplinks are administratively down per lab design.

If the VM becomes unstable after loading the customer CDB:

1. Stop the services using vsh stop
2. Restore CDB files from the backup directory created in Section 4, Step 1.
3. Run vsh restart and verify service stability.