Colocation Cross-Connect Turnup on Ubuntu Server

Why this turnup matters

A colocation cross-connect only works when the server can see the carrier, pass traffic, and recover cleanly if something is wrong. This guide walks you through a practical colocation cross-connect turnup on Ubuntu Server 24.04, from the first SSH login through routing checks and rollback. It matches the kind of work Hostperl support teams handle during hardware moves: a new rack, a fresh patch panel, a carrier handoff, and a short maintenance window with little room for guesswork.

If you are comparing placement options and remote-hands workflows, Hostperl’s dedicated server hosting and colocation-related operations fit well when you need direct control over hardware and a clean operational handoff. If your move also includes a broader migration plan, this procedure pairs well with colocation remote hands checklist for safer server moves and colocation cross-connect planning for better turnups.

What you will set up

You will confirm the server OS, identify the active NIC, bring up the new interface without breaking SSH, validate link state, set a static address if needed, add route checks, and confirm the carrier path from both the server and a client. The example server IP below uses the reserved documentation address 203.0.113.10; replace it with the real public IP assigned to your server.

Connect to the server and detect Ubuntu

On your local computer, start with the documented SSH login:

ssh root@203.0.113.10

203.0.113.10 is only a documentation example. Replace it with your server’s real public IP before you run the command.

If your host provides a default non-root account, use that instead from your local computer:

ssh deploy@203.0.113.10

Keep the original root session open until you have verified the new login later in the tutorial.

On the VPS as root, detect the operating system:

cat /etc/os-release

You should see Ubuntu 24.04 details. This guide assumes Ubuntu Server because the turnup uses netplan, systemd-networkd or NetworkManager-managed settings, UFW, and AppArmor-aware service handling.

Prepare a non-root admin before touching networking

Use a sudo user for the actual change window. That protects you if the SSH session drops while you are editing network files.

On the VPS as root, create the admin account, grant sudo, and lock password login if you plan to use keys only:

adduser deploy
usermod -aG sudo deploy
passwd -l deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

Then copy your key into place. If you already have a public key on your local computer, append it safely:

printf '%s
' 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyHere your-laptop' > /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal from your local computer and test the new login before you change any SSH or network settings:

ssh deploy@203.0.113.10

Then verify sudo works:

sudo -iu root whoami

If it returns root, you can continue. If not, stop and fix the account first.

Check the current NICs and the carrier handoff

On the VPS as the non-root sudo user, inspect interfaces and routes. This tells you which NIC is live before you touch the new cross-connect:

ip -br link
ip -br addr
ip route

Look for the interface that should receive the new carrier handoff, such as ens3 or eno1. You want to confirm whether it already has an address or whether the turnup requires a new static configuration.

Check link state and errors:

ethtool ens3 || true
ip -s link show ens3

Replace ens3 with your real interface name. A healthy handoff usually shows Link detected: yes and no growing error counters.

Apply the cross-connect address safely with netplan

Ubuntu Server commonly uses netplan. Before editing, back up the current file. The example below assumes a file in /etc/netplan/.

On the VPS as the non-root sudo user, create a backup and open the config:

sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak
sudo nano /etc/netplan/01-netcfg.yaml

Use the following example if the cross-connect should carry a static IPv4 address on ens3 and you want a default route through the colocation carrier. Replace addresses with the values your provider or carrier gave you.

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: no
      addresses:
        - 198.51.100.20/24
      routes:
        - to: default
          via: 198.51.100.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Save the file and exit the editor. Then test the config before applying it. This is the lockout-safe step.

sudo netplan generate
sudo netplan try

netplan try gives you a rollback timer if the interface fails. Accept the configuration only if SSH stays reachable and the address is correct. If the session drops, the change rolls back automatically.

After acceptance, apply it permanently:

sudo netplan apply

Validate the link, address, and route

Now check the interface state again:

ip -br addr show ens3
ip route
ping -c 3 198.51.100.1
ping -c 3 1.1.1.1

You should see the new address on ens3 and successful pings to the gateway and an external IP. If the gateway does not answer, the problem is usually cabling, switch port configuration, or an incorrect next hop from the carrier.

Also confirm DNS resolution works through the new route:

resolvectl query hostperl.com

If name resolution fails but raw IP pings work, fix nameservers in netplan or check the resolver service.

Open the firewall only after the new path works

For turnup work, keep your existing SSH rule and add only what the new service needs. On Ubuntu, UFW is the simplest way to avoid surprises.

On the VPS as the non-root sudo user, allow SSH first if it is not already open, then permit any service ports required by your downstream application or monitoring:

sudo ufw status verbose
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

If the server is only acting as a routed handoff with no public web service, you may not need ports 80 or 443. Keep the rule set as small as the turnup requires.

Confirm the firewall did not block your session:

sudo ufw status numbered

Test carrier reachability and path quality

Basic ping is not enough for colocation. You want to know whether the route is stable, whether latency is reasonable, and whether packets are being dropped.

On the VPS as the non-root sudo user, run a short trace and a packet-loss check:

tracepath 1.1.1.1
mtr -rwzc 20 1.1.1.1

If mtr is missing, install it:

sudo apt update
sudo apt install -y mtr-tiny

Good output shows a stable first hop and no sustained loss. If the first hop drops, the issue usually sits at the cross-connect, patching, or switch port rather than in Ubuntu.

Check logs and systemd state

Before you call the turnup complete, check the networking logs and the system state. This is where you catch misread config files and interface naming errors.

systemctl status systemd-networkd --no-pager
journalctl -u systemd-networkd -b --no-pager | tail -n 50
journalctl -b --no-pager | grep -Ei 'netplan|network|ens3|eno1' | tail -n 50

If the server uses NetworkManager instead of systemd-networkd, replace the status check with:

systemctl status NetworkManager --no-pager
journalctl -u NetworkManager -b --no-pager | tail -n 50

You are looking for clean activation messages, no YAML parse errors, and no repeated link flaps.

Confirm reboot persistence

A good turnup survives a reboot. Schedule this only after you have verified the route and have a recovery path through remote hands or out-of-band access.

On the VPS as the non-root sudo user, review the current netplan file and then reboot:

sudo netplan get
sudo reboot

After the machine comes back, reconnect from your local computer:

ssh deploy@203.0.113.10

Then re-check the interface and route:

ip -br addr
ip route
ping -c 3 1.1.1.1

If these still pass, the cross-connect turnup is persistent and ready for production traffic.

Rollback if the handoff is wrong

When a cross-connect does not behave, rollback should be simple. Restore the backup config, regenerate netplan, and reapply.

On the VPS as root or the non-root sudo user, restore the previous file:

sudo cp /etc/netplan/01-netcfg.yaml.bak /etc/netplan/01-netcfg.yaml
sudo netplan generate
sudo netplan apply

If you lose SSH after a change, wait for netplan try to revert automatically, or use remote hands to restore the backup through console access. Do not keep retrying random edits; that burns the maintenance window.

Troubleshooting the most likely failures

1. The interface shows no carrier.
Run:

ip -br link show ens3
ethtool ens3

If Link detected: no appears, ask remote hands to reseat the patch, confirm the correct switch port, and verify the cross-connect label.

2. SSH works, but the new route does not.
Run:

ip route
ping -c 3 198.51.100.1
traceroute -n 1.1.1.1

If the gateway is unreachable, the next hop or subnet mask is wrong. Correct the netplan addresses and routes, then reapply.

3. Netplan refuses the file.
Run:

sudo netplan generate

YAML indentation errors are the usual cause. Fix spacing, confirm interface names, and try again.

4. The server reboots but the address is gone.
Run:

sudo netplan get
ls -l /etc/netplan/

Check that the file exists, belongs in the correct location, and still contains the static address stanza.

Where Hostperl fits

If you are moving hardware into a rack or validating a carrier handoff, the work goes faster when the hosting team understands remote hands, routing, and post-move verification. Hostperl supports customers who need that kind of operational clarity on dedicated servers and colocation-style infrastructure, not just a box on a sheet. For broader planning around power and density before the turnup, keep colocation power density planning for rack stability in your preparation notes.

FAQ

Do I need a static IP for a colocation cross-connect?
Usually yes. Most production handoffs use static addressing so route changes and firewall rules stay predictable.

Can I keep SSH open while changing the network file?
Yes, but use netplan try first and keep a second terminal open. That gives you a rollback window if the interface comes back incorrectly.

What if my carrier gives me a /31 or /30?
Use the exact subnet they provide. Do not widen it. A wrong prefix length is one of the fastest ways to break reachability.

Should I test from inside the same data center?
Yes. Test both from the server and from an external client. The server confirms local routing, while the client confirms the service is actually reachable end to end.

What is the safest final check before opening traffic?
Reboot the server, reconnect over SSH, confirm the interface address, and run one external ping and one trace. If all three pass, the turnup is stable enough for production use.