2 AM. Phone buzzing. Lead dev messages: “Server can’t connect to the database, check the network.” I roll out of bed, SSH into the jump host — bare-bones machine, nothing installed except bash. My gut says subnet overlap between the VLAN we added yesterday and the old IP range.
Managing the network for a 50-person office plus a small datacenter, this kind of situation always hits at the worst possible moment — late at night, no tools on the machine, deadline looming. This post cuts straight to the online tools I keep bookmarked, ready to use the moment you only have a browser.
Quick Start: 3 Tools to Use in Under 5 Minutes
1. Subnet Calculator — solve CIDR problems instantly
The first thing I open when I suspect a subnet conflict is a Subnet Calculator. It instantly computes the network range, broadcast address, and number of usable hosts from any IP/CIDR input.
I use the ToolCraft Subnet Calculator — clean interface, runs 100% in the browser without sending anything to a server. That matters when you’re entering production IPs and don’t want to expose your internal network topology.
Example: database server at 10.10.20.5/24, app server at 10.10.20.100/24. Plug them in and you immediately see:
Network: 10.10.20.0
Broadcast: 10.10.20.255
Host range: 10.10.20.1 — 10.10.20.254
Usable: 254 hostsBoth are /24, same subnet, internal routing. So the issue isn’t here. Time to check DNS.
2. DNS Lookup — when a hostname resolves to the wrong IP
The connection string in the code uses a hostname instead of a direct IP. dnschecker.org is what I open next — enter the hostname, and it queries from 20+ global locations simultaneously. Incredibly useful right after changing a DNS record, since you can see exactly which locations have already propagated and which are still serving the old cached value.
Result: the database hostname was pointing to the old IP, never updated after last week’s server migration. Case closed at 2:23 AM.
3. IP / Subnet Mask Converter — when the team uses mixed notations
A common situation: the firewall rule is written as 10.10.20.0/255.255.255.0, but the AWS security group requires CIDR notation 10.10.20.0/24. Converting subnet mask ↔ CIDR prefix is something I do regularly when configuring across platforms.
The fastest approach is just using the Subnet Calculator — enter one format and it outputs both. No need to open another tab.
Going Deeper: Using the Right Tool at the Right Time
Subnet Calculator — using it properly
Calculating /24 or /16 is just the most basic use case. Here are more common real-world scenarios:
- Subnetting: You have
192.168.10.0/24and need to split it into 4 VLANs. Calculate /26 → 62 hosts per subnet, 4 subnets fits perfectly. - Overlap check: Do two routes overlap? Enter each one and compare the host ranges.
- VLSM planning: Assign different subnet sizes per department — accounting needs 10 hosts, dev needs 50 — pick the right prefix for each group.
With ToolCraft, enter an IP + subnet mask or CIDR notation, and the tool auto-converts and displays everything: network address, broadcast, first/last host, wildcard mask, and binary representation.
The binary section might seem like overkill. But when you need to explain to junior teammates why /24 only gives you 254 hosts and not 256 — pull up the binary view, point directly at the 8 host bits, and it clicks much faster than any verbal explanation.
DNS Lookup — knowing which tool to use
Three different situations call for three different tools — use the wrong one and you’ve wasted another 5 minutes debugging nothing:
- Checking a specific record:
digornslookupfrom the terminal is fastest. When you don’t have CLI access, use nslookup.io — enter the domain, select the record type (A, MX, TXT, CNAME), and query from a custom DNS server if needed. - Checking DNS propagation: Just changed a record and need to see how far it’s spread — dnschecker.org queries from multiple locations so you can see which ones haven’t updated yet.
- Debugging mail servers: MX records, SPF, DKIM, DMARC — mxtoolbox.com has the most complete suite, and it checks blacklists while you’re at it.
When you’re troubleshooting and need a quick DNS query from the terminal:
# Query A record
dig A db.internal.company.com
# Query from a specific DNS server
dig @8.8.8.8 A db.internal.company.com
# Check MX record
dig MX company.com +short
# Reverse lookup (PTR)
dig -x 10.10.20.5
# Check remaining TTL
dig A hostname.com +ttlidIP Converter — common conversions
- Subnet mask ↔ CIDR prefix:
255.255.255.0=/24,255.255.254.0=/23,255.255.252.0=/22 - IP decimal ↔ hex: Reading logs from older devices or Cisco configs that output hex
- IPv4-mapped IPv6: Dual-stack servers logging
::ffff:10.10.20.5— you need to know this is actually an IPv4 address
For subnet mask ↔ CIDR, the ToolCraft Subnet Calculator handles it automatically on input. For hex conversion, Python is faster than any online tool:
import ipaddress
# Convert IP to integer and hex
ip = ipaddress.ip_address('10.10.20.5')
print(int(ip)) # 168497157
print(hex(int(ip))) # 0xa0a1405
# Parse network, calculate host range
net = ipaddress.ip_network('10.10.20.0/24')
print(f"Usable hosts: {net.num_addresses - 2}")
print(f"First host: {next(net.hosts())}")
print(f"Last host: {list(net.hosts())[-1]}")
print(f"Broadcast: {net.broadcast_address}")Advanced: Combining Tools When Troubleshooting
Automated subnet overlap check script
When adding a new VLAN to the network, I run this overlap check script before configuring the router:
import ipaddress
def check_overlap(networks):
"""Returns a list of overlapping subnet pairs"""
nets = [ipaddress.ip_network(n, strict=False) for n in networks]
conflicts = []
for i, n1 in enumerate(nets):
for n2 in nets[i+1:]:
if n1.overlaps(n2):
conflicts.append((str(n1), str(n2)))
return conflicts
# Currently used subnets
existing = [
"10.10.10.0/24", # VLAN10 - Office
"10.10.20.0/24", # VLAN20 - Servers
"10.10.30.0/24", # VLAN30 - DMZ
"192.168.1.0/24", # Management
]
new_subnet = "10.10.20.128/25" # New subnet to add
conflicts = check_overlap(existing + [new_subnet])
if conflicts:
print("CONFLICT DETECTED:")
for c in conflicts:
print(f" {c[0]} overlaps {c[1]}")
else:
print("No conflicts. Safe to add.")Connectivity debug workflow
When a “can’t connect” ticket comes in, I follow this flow:
- Layer check: Can you ping the IP directly? If yes → DNS/app layer. If no → network layer.
- Subnet check: Are source and destination on the same subnet? If not, does the gateway have a route?
- DNS check: What IP does the hostname resolve to? Is it correct? From multiple locations?
- Port check: Is the service actually listening?
#!/bin/bash
# Quick network debug — log results to file
TARGET="db.internal.company.com"
PORT=5432
LOGFILE="/tmp/netdebug-$(date +%Y%m%d-%H%M).log"
{
echo "=== $(date) ==="
echo "--- DNS ---"
dig A $TARGET +short
echo "--- Ping ---"
ping -c 3 $TARGET 2>&1
echo "--- Port $PORT ---"
nc -zv $TARGET $PORT 2>&1
echo "--- Route ---"
ip route get $(dig A $TARGET +short | head -1) 2>&1
} | tee $LOGFILE
echo "Log saved: $LOGFILE"The tee at the end lets you watch in real time while saving the log. Next morning when you write the incident report, all the data is right there — no trying to reconstruct what happened.
Practical Tips
Bookmark Before You Need Them
Create a “Network Tools” bookmark folder with 4–5 tools you already know how to use. At 2 AM you don’t want to be searching through pages of ads.
My bookmark folder:
- ToolCraft Subnet Calculator — subnet/CIDR/wildcard, runs offline, no risk of leaking internal IPs
- dnschecker.org — DNS propagation from multiple locations
- mxtoolbox.com — debug mail, SPF/DKIM/DMARC, blacklist check
- nslookup.io — DNS queries from a custom server
Prefer client-side tools when entering sensitive IPs
Before entering production IPs or hostnames into an online tool, ask yourself: does this send data to their server? ToolCraft runs all calculations in JavaScript right in your browser — no outbound requests. That makes it safe for entering internal IP ranges or sensitive network topology.
DNS checkers are the opposite — by design, they query from multiple locations, so your hostname goes through their servers. That’s fine for public domains, but avoid using them for internal hostnames.
CLI is still faster for some things
Online tools are handy when you don’t have a proper environment. But once you’re SSHed into a server, ipcalc is faster than switching browser tabs:
# Install ipcalc
apt install ipcalc # Debian/Ubuntu
yum install ipcalc # CentOS/RHEL
# Usage — output equivalent to online Subnet Calculator
ipcalc 10.10.20.5/24
# Output:
# Address: 10.10.20.5
# Netmask: 255.255.255.0 = 24
# Network: 10.10.20.0/24
# HostMin: 10.10.20.1
# HostMax: 10.10.20.254
# Broadcast: 10.10.20.255
# Hosts/Net: 254Both give you the same result. Use the online tool when you don’t have CLI access, use ipcalc when you’re already inside the server.
