> For the complete documentation index, see [llms.txt](https://docs.layeronecloud.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.layeronecloud.com/network-monitor/operations/devices-and-applications.md).

# Device identification and applications

A MAC address is an address, not a name.

## Device identification <a href="#device-identification" id="device-identification"></a>

A MAC address is an address, not a name. Every view labels a device with the best name known for it and keeps the MAC in its own column: an operator name first, then the matched Pulsar Operations VM name, then the manufacturer, and only the MAC when nothing else identifies it.

Each device carries the billing match last confirmed for it, so the inventory page reads owners and VM names straight out of the database instead of matching every device on the site against imported inventory on every load. Each import restates them, and a page load brings any device the loop has not reached yet up to date. Inventory that is unreachable, disabled, or stale is not an answer, so it leaves those matches alone: a customer machine keeps the name and owner it was last confirmed to have, and the page says the inventory behind them is old rather than reverting every device to its MAC address.

Manufacturers come from a bundled prefix table that resolves the virtualization and adapter vendors offline during ingestion, and from the public OUI registry for everything else. `resolve_mac_vendors` runs both passes: the offline one over the whole backlog, then a paced registry pass bounded by `--limit` (200 by default). Only the 24-bit vendor prefix leaves the network, a resolved device is never looked up again, and a failed lookup backs off for twelve hours. Set `L1_MAC_VENDOR_LOOKUP_URL` empty to keep identification entirely offline, or pass `--offline` for a single pass. A MAC with the locally administered bit set is reported as randomized rather than looked up, and is never used as a name.

Operators with configuration access can name a device from the inventory table or its detail page. The name is attached to the MAC address, so every segment that address appears on is renamed together, and it outranks both the billing inventory and the manufacturer. Clearing the name restores automatic identification.

## Applications <a href="#applications" id="applications"></a>

The dashboard and Applications page default to **Internet / Outbound**, which answers which external services local devices initiated. Select **Inbound** to inspect hosted services reached from the Internet, **LAN / Internal** for device-to-device traffic, or **All** when a combined operational view is useful. Each application row expands to at most ten destinations and ten devices; the counts alongside those lists are computed before truncation. Device labels use the same operator, inventory, manufacturer, then MAC precedence as the rest of the console.

Hover or focus a Top Applications row to see up to five source/client → destination/service IP pairs. Expand the row on touch devices. The Applications table shows the busiest pair under Top connection. To investigate external clients reaching a hosted service such as Proxmox, select Internet / Inbound. Pair counters separate bytes sent to the service from replies. Port-based names and client/service roles are inferred from traffic and do not establish that a login succeeded. When no pair is available, the device list is explicitly labeled as fallback attribution. Partial details and windows extending beyond 24 hours are identified in the panel.

Names are evidence-backed rather than inferred from every ephemeral port. TLS SNI, HTTP Host and CONNECT, and DNS A/AAAA/CNAME answers can identify a destination. The sensor honors DNS TTLs, reduces hostnames locally to a registrable domain with its pinned Public Suffix List, and reports a canonical remote IP when no domain is available. QUIC has DNS fallback only; it does not gain a name from direct QUIC Initial decoding. On the server, a known domain rule wins, then the transport/port catalog classifies any unknown domain or IP. Expand a row to see the destination evidence rather than treating the resulting application name as deep packet identification.

Agent 0.1.13 also names recognized IP protocols without requiring TCP or UDP: GRE, IPsec ESP/AH, IP-in-IP, IPv6-in-IP, IGMP, OSPF, and SCTP. These labels come from the observed IP protocol number and take priority over destination-domain rules; they do not identify applications inside a tunnel. IPv6 AH extension headers continue to be traversed to the encapsulated transport, so the AH label currently applies to IPv4. The control plane advertises `application_protocol_version: 1`; older control planes receive the existing generic IP fallback. Deploy the server before upgrading sensors. Historical rows already stored as generic IP cannot be separated retroactively.

Most sites need no application-boundary configuration. For public routed or bridged ranges that are locally owned but are not directly assigned to the sensor host, configuration administrators can manage up to 128 CIDRs with:

```
GET /api/v1/sites/{site_id}/application-settings
PUT /api/v1/sites/{site_id}/application-settings
{"local_cidrs":["203.0.113.0/24","2001:db8:1234::/48"]}
```

These CIDRs only determine which endpoint is local for application direction. They are deliberately separate from **Additional protected CIDRs** in DDoS configuration: changing one list does not change the other.

The application tracker is bounded to 32,768 flows per capture and 131,072 per process, inspects at most 4 KiB of client data per flow within a 32 MiB process budget, and emits at most 4,096 usage keys per minute. When traffic exceeds the full-detail, device/port, or port-only tiers, bytes fall into direction-specific overflow without being discarded. Collection notices expose packet coverage, domain/device/port attribution ratios, and `detail_truncated`; treat partial detail as partial evidence, not as zero traffic.

Collection notices also show how many packets could not be parsed. The `parser_dropped` counter counts packets delivered by libpcap that the packet parser rejected, separately from capture-buffer drops and unidentified applications. Any reported parser loss makes an otherwise complete application window partial; the lost packets' bytes are not estimated or added to application usage. Linux interface byte totals still come from the kernel counters. The count covers contributing captures for the notice's selected time window, not an individual application's packets. It is also retained on live and minute interface-total metrics, including minutes with no successfully parsed packets.

Deploy the control plane with migration `0051_parser_loss_counters`, then install the rebuilt sensors to collect parser-loss counts. Older sensors and existing history default to zero; this does not prove those packets were all parsed and cannot recover previously unreported losses.

For each site-minute, traffic scope, and connection direction, Internet traffic is counted at the uplink: WAN facts are authoritative whenever the WAN capture observed eligible traffic, and LAN facts stand in only while the uplink is idle or absent. A guest bridged straight onto the uplink is therefore never hidden by an unrelated bridge's traffic, and a routed flow seen on both captures is counted once. Internal (LAN) traffic is owned by the bridges in the same way. Devices behind a router or NAT gateway are still named from the bridge's superseded observations; those rows carry a `vantage` of `bridge` beside the uplink's own `uplink` rows and add names, not bytes. The Applications page also ranks the busiest destinations across every application for the selected traffic and direction. Overlapping LAN/WAN capture facts are never added together. Upgrading to this rule rotates each WAN's membership epoch once, because the persisted binding gains its evidence fields. The minute facts and coverage markers are held for three months in the daily-partitioned `monitoring_application_usage_minute` and `monitoring_application_usage_coverage_minute` tables.

Exact client/service pairs and their classification summaries use separate daily partitions with a rolling 24-hour retention window. The API and ingestion enforce this cutoff immediately; hourly `maintain_metrics` removes expired rows including the expired portion of a daily partition. Physical deletion can lag by up to one maintenance interval. Keep this job scheduled hourly on custom deployments.

Deploy the server migration and control-plane capability first, then upgrade sensors. A compatible control plane advertises `application_usage_version: 1`; the sensor leaves destination-aware emission off when an older server does not advertise it. There is intentionally no backfill from generic port metrics. Until a site reports destination-aware minutes, the UI reports collecting, upgrade-required, or not-configured state; ready means the selected window has clean new data, while partial can indicate capture loss or exhausted detail bounds. It never blends legacy port-only rows into the new ranking.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.layeronecloud.com/network-monitor/operations/devices-and-applications.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.