← All posts
Jun 28, 2026

Two Devices, One IP: How Weavestream Catches Address Conflicts Before They Cause an Outage

Duplicate IPs cause some of the hardest network problems to diagnose. Weavestream's IPAM auto-discovers occupied addresses from your asset records, flags conflicts automatically, and shows you exactly which addresses are free — no spreadsheet required.

A duplicate IP address is one of the most frustrating problems a technician can chase. Nothing is “down” in an obvious way. A workstation drops off the network intermittently. A printer answers pings sometimes and not others. A new server you just racked refuses to behave, and three hours later someone realises the static IP you assigned it was already pinned to a switch management interface that nobody documented.

The fix is trivial once you find it. Finding it is the expensive part — because the information you need to avoid the conflict in the first place usually doesn’t exist in any single place.

Most MSPs track IP assignments in a spreadsheet, a wiki page, or in someone’s memory. None of those tell you, at the moment you’re about to assign 10.0.20.45 to a new device, that something else is already using it. So the conflict gets created, shipped, and discovered the hard way.

Weavestream’s IPAM is built to catch this before it happens. Instead of treating your IP records as a static list someone has to keep current, it derives occupancy from the asset records you’re already maintaining and flags conflicts automatically.

Occupancy Is Discovered, Not Typed

This is the part that changes the workflow. In Weavestream, any asset field of type IP_ADDRESS is automatically cross-referenced against your subnets. When you document a server, firewall, switch, or workstation and record its IP, that address is auto-discovered as an occupant of whatever subnet it falls inside.

You don’t maintain a second list of “which IPs are taken.” The subnet’s occupancy is computed from the asset documentation you’re already creating as part of normal onboarding and support work. Document the device once, and its address shows up in the subnet view automatically.

That’s a meaningful difference from a spreadsheet, where the IP column and the asset inventory are two separate things that drift apart the moment someone forgets to update one of them. Here, the asset record is the source of truth, and the IPAM view reflects it.

Conflict Detection That Runs on Its Own

Because occupancy is derived from asset data, Weavestream can do something a spreadsheet fundamentally can’t: detect when two assets claim the same address.

If two asset records inside the same subnet share an IP, the subnet flags it as a conflict. You don’t run a report or remember to check — the conflict surfaces on the subnet detail page and in the address-space view, marked distinctly from healthy addresses. The moment a duplicate exists in your documentation, it’s visible.

For an MSP, this turns IP conflicts from a runtime incident into a documentation-time warning. The conflict is caught when someone records the second device, not at 2am when a critical host starts flapping. That’s the entire value of the feature: it moves the discovery of the problem to a point where fixing it costs five minutes instead of half a night.

The Address-Space View

Each subnet includes an address-space view that lays out the range and marks the status of every address:

  • Free — available to assign
  • Asset-occupied — in use by a documented asset
  • Reserved — manually held for a device or service
  • Conflict — claimed by more than one asset
  • Network / broadcast — reserved by the prefix itself (for /30 and larger)

When you’re about to assign an address, you don’t guess. You look at the subnet and pick something marked free. The view answers the question that actually causes conflicts — “what’s safe to use here?” — without anyone having to maintain a separate availability list.

For very large ranges, the view automatically switches from a full grid to a compact list of assigned addresses, so a /16 doesn’t try to render sixty-five thousand cells. You get the same answer either way: what’s taken, what’s reserved, what’s in conflict, and what’s open.

Utilization at a Glance

Every subnet shows utilization as used / free / total usable. This sounds mundane until you’re planning capacity for a client whose network was carved up years ago by someone who no longer works there.

A subnet sitting at 90% utilization is a renumbering conversation waiting to happen. One at 5% is a candidate for consolidation. Having that number visible per subnet — across every client, computed from real asset data rather than a stale estimate — makes capacity planning something you can actually do during a quarterly review instead of something you discover when you run out of addresses mid-deployment.

Reservations for the Things That Aren’t Assets Yet

Not everything with an IP is a full asset record. A planned gateway, a VIP, a DHCP exclusion range, a device you’re provisioning next week — these need to be held without being modelled as complete assets.

Weavestream supports manual reservations for exactly this. A reservation is a named hold on a specific address, validated in real time and server-side: the IP has to be valid IPv4, it has to fall inside the target subnet, and it has to be unique within that subnet’s reservations. You can’t accidentally reserve something outside the range or double-book a held address.

Reservations and auto-discovered occupants appear together in the subnet detail view, so the address-space picture is complete — both the devices you’ve documented and the holds you’ve placed for what’s coming.

It Lives Next to Everything Else About the Client

The reason this works is that IPAM isn’t a bolted-on tool with its own database. It’s part of the same platform as your asset records, credential vault, and client documentation. The IP data and the device documentation are about the same client, so they live in the same place.

When a technician is troubleshooting a network issue, the subnet, the occupant assets, and the credentials for those devices are all one click apart — not in a separate phpIPAM instance behind a different login that someone has to remember under pressure. That co-location is what makes the conflict detection genuinely useful: catching a conflict only helps if you can immediately see what the conflicting device is and who owns it.

Clients Can See It Too — Read-Only

IPAM is available in the client portal as a read-only experience. Client users can see the subnet list with utilization and conflict indicators, and drill into per-subnet detail showing occupants, reservations, and the address space.

For clients with in-house IT who co-manage their environment, this is a clean way to share network documentation without giving anyone write access or a seat in your admin console.

Everything Is Scoped and Audited

IPAM is tenant-scoped by company. Read operations require asset.read within the company and write operations require asset.write, so the same role model that governs the rest of your documentation governs IP data too. There’s no separate permission system to configure.

Subnet and reservation changes are written to the audit log — create, update, archive, and restore for subnets, and create, update, and delete for reservations. If a subnet definition changes or a reservation disappears, there’s an immutable record of who did it and when. For MSPs with compliance obligations, IP address management stops being an undocumented blind spot and becomes part of the same audit trail as everything else.

The Practical Setup

If you’re already documenting assets in Weavestream, most of the work is done. To get conflict detection working for a client:

  1. Create the client’s subnets under their company — name, CIDR, optional VLAN and gateway, and notes.
  2. Make sure your asset layouts include an IP_ADDRESS field for anything with a static address (servers, network gear, printers, infrastructure).
  3. Populate those IP fields as you document or sync devices.
  4. Open the subnet detail page and check the address-space view and utilization.

From that point on, occupancy and conflicts are computed automatically. Every new device a technician documents either fills a free address or lights up as a conflict — no spreadsheet to update, no separate tool to reconcile.


Weavestream is a free, self-hosted, open-source IT documentation platform for MSPs and IT teams. It runs on Docker and Postgres, and includes IPAM with conflict detection, asset management, an encrypted credential vault, domain and SSL monitoring, a client portal, and audit logging. Find out more at weavestream.io.

← All posts