Communication Views in CMDB: How to See Host-to-Host Traffic Flows, Ghost Machines, and Open Ports

A CMDB tells you what devices you know about and how you have documented their relationships. It does not tell you what those devices actually do on the network right now. That gap, between documented relationships and actual network communication, is where security risks hide, where change management assumptions break, and where incident investigations stall.

IT visibility into actual network communication is no longer optional for IT teams running hybrid infrastructure with cloud workloads, containers, and devices provisioned outside formal IT processes. Virima 6.1.1 addresses this gap with the ViVID Communication View, a capability that surfaces live host-to-host traffic flows, open port numbers, and ghost machines directly within the service mapping interface.

What Is a Communication View in CMDB?

A communication view in a CMDB is a visualization of actual network traffic between devices, based on data collected by IT Discovery scans rather than manually documented relationship records. Where a standard CMDB relationship map shows the relationships that IT has formally recorded (for example, “Application A runs on Server B”), a communication view shows the traffic that is actually flowing between hosts on the network. For more on how application dependency mapping fits into this picture, see our detailed guide.

This distinction matters because documented relationships and actual network communications are rarely identical. Applications communicate with services that were never formally catalogued. Servers talk to endpoints outside their intended configuration. Devices that were never officially provisioned appear on the network and communicate freely.

A communication view makes this real-world behavior visible. It shows:

• Host-to-host traffic flows: which devices communicate with which other devices, and in which direction
• Open port numbers: the specific ports through which communication occurs
• Traffic direction: whether communication is bidirectional or unidirectional
• Ghost machines: devices that appear in network traffic but do not exist as CI records in the CMDB

In Virima ViVID, this view is rendered as an interactive, filterable diagram that IT operations teams, security teams, and network administrators can explore without writing a single query or exporting data to a spreadsheet.

The Problem Ghost Machines Create

Ghost machines are devices that communicate on the network but are not recorded in the CMDB. They exist for many reasons: a developer spun up a test VM that was never formally registered, a vendor left a management appliance on the network after a project, a contractor connected a personal device to an internal segment, or an old server was decommissioned in the asset register but never physically removed from the rack.

Regardless of origin, ghost machines create three categories of risk.

Change management risk

When a change plan assumes a server has three dependent devices and a ghost machine is actually a fourth dependent device that no one knows about, the change produces unexpected outcomes. The ghost machine is not in the CMDB, so it appears in no dependency analysis, no blast radius calculation, and no stakeholder notification. It fails silently during the change window.

Security risk

Ghost machines are by definition unmanaged. They receive no patch management, no endpoint security agent, and no vulnerability scan coverage. An unmanaged device with full network access represents a persistent attack surface. Security teams cannot remediate vulnerabilities on devices they do not know exist.

Audit and compliance risk

Regulatory frameworks that require a complete asset inventory, including PCI DSS, HIPAA, and ISO 27001, do not make exceptions for devices that IT did not officially provision. A ghost machine on a network segment that processes sensitive data is a compliance finding waiting to happen.

Traditional CMDB discovery processes catch most devices that IT officially manages. They miss ghost machines almost by definition, because ghost machines exist outside formal IT processes. The only way to find them is to observe actual network communication and compare it against the CMDB. That is exactly what the ViVID Communication View does.

How Virima ViVID Communication View Works

Virima Discovery scans the network and collects data on active communications between hosts. This data includes the source and destination IP addresses, the ports in use, the direction of traffic, and the frequency of communication. The Discovery process detects these communications without requiring agents on every device, which is how it captures traffic from devices that have no managed software installed.

ViVID renders this communication data as an interactive network diagram. Each node represents a host, and each edge represents an active communication channel. The visualization includes:

• Flow lines between host nodes, with directional arrows showing which device initiates communication
• Port badges attached to flow lines, showing the specific open port numbers through which each communication occurs
• Ghost machine indicators: nodes that appear in the communication data but have no corresponding CI record in the Virima CMDB are flagged visually, separated from documented CIs

The map is filterable. Users can narrow the view by network segment, CI type, communication direction, or port number. For large environments with many hosts, filters make the communication view navigable rather than overwhelming.

The ViVID Communication View is available in Virima 6.1.1 and works alongside the standard application dependency and network topology views within the same ViVID interface.

Practical Use Cases for Communication Views

Security Audits

During a security audit, the communication view answers questions that the CMDB alone cannot: what devices are communicating on ports that security policy prohibits? Which hosts send traffic to external IP ranges that are outside approved destinations? Where do ghost machines sit in relation to sensitive data segments?

Auditors and security operations teams use the communication view to validate network segmentation, confirm that firewall rules match actual traffic patterns, and surface unauthorized communication channels before they become incident findings.

Change Planning

Before any change that affects network routing, firewall rules, or shared infrastructure, the change planner uses the communication view to understand which hosts actually communicate through the affected path. If a firewall rule change blocks traffic on port 443 between two segments, the communication view shows every host pair that currently uses that path. The change planner can notify all affected application owners, not just the ones whose applications appear in formal CMDB documentation.

Incident Analysis

When an incident involves unusual application behavior, the communication view answers the question “what changed in the traffic pattern?” If a server that previously only communicated with its application tier now shows traffic to an external address, that anomaly is visible in the communication view. Incident responders use this as a forensic tool to understand what network behavior preceded or accompanied a failure.

Network Segmentation Review

Organizations that are re-segmenting their networks (a common project during zero-trust architecture transitions) need an accurate picture of which hosts communicate across proposed segment boundaries. The communication view generates this picture from observed traffic rather than from assumptions in network diagrams that may not reflect current reality.

How Communication Views Complement Traditional CI Relationship Maps

Traditional CI relationship maps in a CMDB show the formal, documented relationships between configuration items and represent the CMDB CI relationship used in service mapping. They answer the question: “Based on what we have recorded, what is connected to what?” The communication view answers a different question: “Based on what is actually happening on the network, what is talking to what?

These two views are complementary, not redundant. The formal relationship map provides the planned architecture view. The communication view provides the operational reality view. Comparing them reveals gaps that affect CMDB accuracy:

• Relationships that exist in documentation but produce no actual traffic (possibly indicating retired integrations or misconfigured services)
• Communications that occur on the network but have no corresponding CI relationship in the CMDB (possibly ghost machines, shadow IT, or undocumented integrations)
• Traffic on unexpected ports suggests a service is not operating as configured

IT teams that use both views together maintain a CMDB that reflects what the environment is designed to look like and what it actually looks like. The gap between those two pictures is where most CMDB health problems hide. For a broader view of how Virima positions CMDB and ITSM data together, see ITSM Data Strategy: Maximizing ITSM Value with CMDB.

What to Do When You Find Ghost Machines

The ViVID Communication View surfaces ghost machines. What comes next depends on what each ghost machine turns out to be.

Step 1: Identify the device

Use the IP address and communication patterns visible in the ViVID view to identify the device. DNS lookups, MAC address vendor lookups, and communication port analysis narrow down the device type and likely owner.

Step 2: Classify the device

Is this a legitimate managed device that was simply missed by the discovery configuration? Is it a test or dev resource that was never formally registered? Is it a vendor appliance? Is it an unauthorized device?

Step 3: Take action based on classification

• Legitimate managed devices: run a targeted Discovery scan, create or update the CI record in the CMDB, and assign it to the appropriate owner and service context.
• Unregistered test or dev resources: register them formally in the CMDB, assign ownership, and bring them under patch management and security monitoring.
• Vendor appliances: verify with the vendor that the device is authorized, document it in the CMDB, and confirm it is covered by the vendor support agreement.
• Unauthorized devices: escalate to the security team for investigation and removal per incident response policy.

Step 4: Schedule recurring reviews

Ghost machine discovery is not a one-time event. Schedule regular communication, view reviews as part of CMDB health management. New ghost machines will appear as the environment changes.

The CMDB gains meaningful completeness not just from scheduled discovery scans but from the communication view, acting as a continuous audit against what the CMDB says the network should look like.

Conclusion

A CMDB without communication visibility is a documentation system. A CMDB with communication visibility is an operational tool. The ViVID Communication View in Virima 6.1.1 bridges that gap by showing IT teams the actual traffic flows, port numbers, and undocumented devices that formal CI relationship records miss.

For IT operations teams that need to know exactly what is on the network, not just what should be, the communication view provides that ground truth.

Schedule a Demo to see the ViVID Communication View in action across your environment.

Frequently Asked Questions

What is a ghost machine in a CMDB?
A ghost machine is a device that actively communicates on the network but does not have a corresponding CI record in the CMDB. Ghost machines typically result from informal provisioning, decommissioning processes that remove the asset record without removing the physical device, or unauthorized devices connected to the network. Virima ViVID’s Communication View flags ghost machines automatically by comparing observed network traffic against CMDB CI records.

How does Virima detect host-to-host traffic flows?
Virima Discovery scans the network to collect data on active communications between hosts, including source and destination IP addresses, open port numbers, and traffic direction. This data feeds into the ViVID Communication View, which renders it as an interactive, filterable diagram. The process works without agents on every device, which is how it captures traffic from unmanaged and undocumented hosts.

Why do open port numbers matter in a CMDB communication view?
Open port numbers reveal the specific channels through which devices communicate. Port-level visibility allows security teams to identify unauthorized services, verify that applications operate on approved ports, and detect unusual communication patterns, such as a database server accepting inbound connections on a port associated with remote access tools, that suggest misconfiguration or compromise.