DEV Community: Frank Zhang

Interoperability in Multi-Vendor Switch Migration: VLAN Trunking, MSTP, and LACP

Frank Zhang — Wed, 09 Sep 2026 06:33:59 +0000

During phased switch migrations, old and new networks often operate in parallel. Reliable multi-vendor interoperability depends less on matching command syntax than on ensuring that both platforms interpret VLAN trunking, spanning tree and link aggregation parameters in the same way.

Scope of this article

This article explains the Layer 2 checks that matter when switches from different vendors must coexist during a migration. It focuses on VLAN and untagged-frame handling, MSTP region consistency, standards-based link aggregation, appropriate MTU troubleshooting and a staged validation workflow.

1. Multi-vendor interoperability depends on consistent behavior

In enterprise network upgrades, core switch replacements and campus modernization projects, it is common to connect switches from different vendors. An organization may replace its existing core switches with equipment from another vendor while keeping the current access layer in service. To maintain business continuity, the old and new environments often need to operate in parallel during a phased migration.

At first glance, interoperability may seem straightforward: if both sides support VLAN trunking, spanning tree and link aggregation, the switches should communicate without difficulty. In practice, most interoperability issues are not caused by a lack of standards support. They more often result from differences in default settings, VLAN handling, spanning-tree parameters or link aggregation modes.

Validation therefore requires more than checking whether an interface is Up or confirming that both sides are configured as trunk ports. What matters is whether the devices follow the same standards and interpret the relevant parameters consistently. Three areas deserve particular attention: VLAN trunking and PVID behavior, MSTP region configuration, and LACP-based link aggregation.

2. VLAN trunking is more than an allowed VLAN list

Most modern switches use IEEE 802.1Q for VLAN trunking, so basic VLAN tagging is generally interoperable across vendors. The more common source of problems is how each device handles PVIDs, native VLANs and untagged traffic.

On an 802.1Q trunk, most VLAN traffic is transmitted with a VLAN tag. However, an untagged VLAN is often still present on the link. Depending on the vendor, this may be described as the PVID, native VLAN, default VLAN or untagged VLAN.

Consider a simple example. One switch uses VLAN 10 as the PVID, while the switch at the other end of the trunk still uses VLAN 1 as its native VLAN. The physical link may remain fully operational, and tagged traffic for most VLANs may continue to pass normally. However, untagged frames received at each end will be classified into different VLANs.

This mismatch can cause management access failures, DHCP problems, intermittent connectivity for certain devices or unexpected control-plane behavior. Because the trunk itself remains Up, these issues can be harder to diagnose than a complete link failure.

During migration, the allowed VLAN list should therefore be only one part of the validation. PVID and native VLAN behavior must also be checked explicitly. Where possible, deliberately define and match the untagged VLAN on both ends of an inter-switch link instead of relying on vendor defaults.

3. MSTP compatibility requires a consistent region configuration

Spanning Tree Protocol is critical during a multi-vendor migration, especially when redundant links exist between core, distribution and access layers. An incorrect spanning-tree configuration may cause unexpected link blocking or, in more serious cases, create a Layer 2 loop.

Standards-based protocols such as RSTP or MSTP are generally preferable to vendor-specific spanning-tree implementations. MSTP is especially useful in larger networks where different groups of VLANs need to follow different forwarding paths.

Simply enabling MSTP on both switches, however, does not guarantee that they operate within the same MST region. An MST region is identified by several configuration elements, most notably the Region Name, Revision Level and mapping of VLANs to MST instances. These values must match for switches to consider themselves part of the same region.

If the parameters differ, the devices may still run spanning tree and maintain connectivity, but the link between them will be treated as a region boundary. The intended per-instance forwarding design may then stop working as expected, and links may be blocked differently from the original topology design.

Before migration, document the existing MSTP configuration carefully. After introducing the new switch, do more than confirm that MSTP is enabled: verify the Region Name, Revision Level and VLAN-to-instance mappings. Where supported, compare the resulting MST configuration digest as an additional consistency check. This is particularly important in campus networks with many VLANs and multiple redundant uplinks.

4. Standard LACP is the preferred choice for link aggregation

Connections between core and distribution switches often use multiple physical links combined into one logical aggregation interface for additional bandwidth and redundancy.

Although nearly all enterprise switches support link aggregation, their operating modes are not always identical. Some platforms support static aggregation, while others also offer vendor-specific negotiation. If the two ends use different modes, every physical interface may appear Up even though the logical aggregation does not form correctly.

For multi-vendor links, standards-based LACP is generally the safest choice. LACP was originally specified in IEEE 802.3ad and is now defined under IEEE 802.1AX. As an open standard, it offers broad interoperability across enterprise switching platforms.

Configure both ends to use LACP rather than pairing LACP on one side with a static aggregation group on the other. Also verify the number of member links, interface speeds and aggregation status.

VLAN trunk configuration is normally applied to the logical aggregation interface rather than independently to each member port. Depending on the vendor, this interface may be called a Port-Channel, Bridge-Aggregation interface, Eth-Trunk or another equivalent name. Checking only physical member ports can therefore miss the configuration that actually controls production traffic.

5. MTU is not a general interoperability fix

A common troubleshooting mistake is to change the MTU when a multi-vendor trunk behaves unexpectedly.

Ethernet defines a minimum frame size of 64 bytes, but this does not mean that the interface MTU should be configured to 64 bytes. These are different concepts. The 64-byte value describes the minimum size of a conventional Ethernet frame. In typical IP networking, MTU describes the maximum Layer 3 packet size that can be carried without fragmentation. Standard Ethernet commonly uses an IP MTU of 1500 bytes.

Artificially reducing MTU will not correct a VLAN, spanning-tree or link-aggregation mismatch. Instead, it may cause unnecessary IP fragmentation or lead to packet drops and application-level connectivity problems.

When a trunk has unreachable VLANs, unstable connectivity or an aggregation that does not form correctly, investigate VLAN handling, PVID/native VLAN configuration, spanning tree and LACP first.

MTU validation is a separate concern when the network uses jumbo frames, storage traffic, virtualization platforms or tunneling technologies with additional encapsulation overhead.

6. A practical staged migration validation approach

Consider a migration in which an existing core switch is replaced by a new switch from another vendor. Instead of moving all production traffic at once, establish a temporary interconnection between the old and new environments and validate each protocol layer individually.

Verify physical link status, speed and duplex operation.
Confirm that both sides use IEEE 802.1Q and permit all required VLANs across the trunk.
Check PVID and native VLAN behavior so that both ends classify untagged frames into the same VLAN.
Review spanning-tree behavior. For MSTP, confirm matching Region Name, Revision Level and VLAN-to-instance mappings, then verify that interconnection ports assume the expected roles.
If multiple physical links are used, confirm that both switches negotiate the bundle with LACP and that every intended member has joined the aggregation group.
Only after Layer 2 behavior is validated, test production services including management VLANs, server VLANs, user networks, DHCP, default gateways and critical applications.

This staged approach makes troubleshooting more manageable. Each completed check eliminates an entire class of potential faults and reduces the risk of moving many services at the same time.

7. Conclusion

There is no inherent reason switches from different vendors cannot interoperate reliably. When both devices follow open standards and are configured consistently, multi-vendor switching environments can operate without difficulty.

Identical feature names do not necessarily mean identical behavior. For VLAN trunking, understand and align PVID and native VLAN handling. For MSTP, match region parameters and VLAN mappings. For link aggregation, standards-based LACP is generally the preferred choice.

A successful migration depends less on whether configuration commands look similar across vendors and more on whether the resulting protocol behavior is equivalent.

In practical network engineering, open standards, consistent parameters and staged validation are usually more valuable than memorizing the configuration syntax of any single vendor.

Industrial Wi-Fi Roaming Optimization in a Metal-Heavy Manufacturing Environment - OpsHome Docs

Frank Zhang — Mon, 07 Sep 2026 11:05:46 +0000

NETWORKING / INDUSTRIAL WI-FI / ROAMING

Industrial Wi-Fi Roaming Optimization in a Metal-Heavy Manufacturing Environment

WI-FIROAMING802.11K/V/RRF DESIGNINDUSTRIAL

In a factory filled with metal machines, storage racks, production lines and moving equipment, strong Wi-Fi coverage alone does not guarantee stable mobility. This case study shows how RF optimization and 802.11k/v/r roaming features improved connectivity for handheld terminals, barcode scanners and AGVs.

Topics: industrial Wi-Fi, roaming, RF design, 802.11k, 802.11v, 802.11r

Scope of this article

This article describes a practical industrial Wi-Fi roaming case: the symptoms observed in production, the sticky-client diagnosis, the RF and roaming changes applied, and the validation performed afterward. It focuses on design principles; exact thresholds and feature compatibility should still be validated against the client devices, access points and applications used at each site.

1. Background: mobility problems on the factory floor

In a modern manufacturing factory, wireless networks are widely used for handheld terminals, production data collection, warehouse operations and automated guided vehicle (AGV) transportation systems.

A factory environment is very different from an office environment. Large metal machines, storage racks, production lines and moving equipment can significantly affect wireless performance.

At this manufacturing site, operators reported frequent wireless interruptions during mobile operations:

Handheld terminals disconnected when moving between production areas.
Barcode-scanning applications became slow.
AGV communications occasionally experienced latency.
Devices remained connected to distant access points even when closer APs were available.

The initial assumption was insufficient Wi-Fi coverage. After investigation, however, the issue proved to be mainly related to wireless roaming behavior and RF design.

2. Problem analysis: overlapping coverage and sticky clients

During the site survey, engineers found that multiple access points provided overlapping coverage. A typical roaming scenario looked like this:

AP-01                         AP-02
Strong signal                 Strong signal

          Client movement →

Client remains connected to AP-01
even when AP-02 becomes a better choice

The mobile device did not immediately switch to the nearer AP. Instead, it continued using the existing connection until the signal became too weak.

This behavior caused several operational symptoms:

Increased packet retransmissions.
Higher latency.
Unstable application sessions.
Temporary communication interruptions.

The problem was identified as a sticky-client issue: the client held on to its current association even after another AP had become the better candidate.

3. Solution design: optimize RF coverage first

The wireless network was optimized in stages. The first step was to improve the RF coverage design rather than simply increase AP transmit power.

Engineers adjusted:

AP placement.
Coverage overlap.
Channel assignment.
Transmit power levels.

The objective was to create controlled roaming areas where mobile devices could discover the next AP before losing connectivity to the current one.

For these industrial mobile scenarios, the design targeted stable coverage around:

RSSI: -65 dBm to -75 dBm

This range provided a practical roaming foundation for the devices tested at the site. It should be treated as a site-specific design target rather than a universal threshold.

4. 802.11k: accelerate neighbor discovery

After RF optimization, enterprise roaming features were enabled. The first was 802.11k, which allows wireless clients to receive information about nearby APs.

Without neighbor information, the client may need to scan multiple channels before it can identify an available AP:

Client scans multiple channels
          →
Finds available APs
          →
Makes roaming decision

With 802.11k, the current AP can provide neighbor information, allowing the client to select candidate APs more quickly:

AP provides neighbor information
          →
Client quickly selects candidate AP

This reduces scanning time while a device is moving through the production environment.

5. 802.11v: guide clients toward a better AP

802.11v allows the wireless infrastructure to recommend a better AP to a compatible client. This can improve both connection quality and load distribution.

For example, the network might compare the current connection with a candidate AP:

Current AP
RSSI: -78 dBm
High client load

Candidate AP
RSSI: -60 dBm
Lower load

The network can guide the client toward the stronger, less-loaded AP. The final roaming decision still depends on client behavior and implementation.

6. 802.11r: reduce transition time

For applications that require low latency, roaming delay must be minimized. 802.11r Fast Transition reduces authentication time during AP switching by preparing security information in advance.

This is especially useful for:

AGV communications.
Industrial handheld devices.
Real-time monitoring systems.

Because client and security compatibility can vary, 802.11r should be tested with the actual production device fleet before broad deployment.

7. Validation in real production routes

After completing the optimization, engineers tested the changes under real production conditions. The validation process included:

Walking tests along production routes.
Monitoring client roaming events.
Checking packet loss.
Testing handheld terminals and industrial devices.

The results showed:

Faster AP transitions.
Fewer connection interruptions.
Improved mobile-terminal stability.
A better user experience while devices were moving.

8. Lessons learned

This case demonstrates that industrial Wi-Fi problems are not always caused by insufficient coverage. Simply increasing AP power may create additional roaming problems by making clients hold on to distant APs for longer.

A stable industrial wireless network requires:

Proper RF planning.
Controlled AP overlap.
Correct channel configuration.
Roaming optimization technologies.
Real-world validation.

In industrial environments, the goal is not merely to provide the strongest Wi-Fi signal.

The goal is to provide stable and predictable connectivity while devices are moving.

Why VMware iSCSI Does Not Get Faster with LACP: NFS, MPIO and 10GbE Explained

Frank Zhang — Wed, 02 Sep 2026 13:17:49 +0000

VMware storage performance depends on the complete I/O path, not only the disks. A fast NAS, NVMe cache, or a large LACP bundle cannot compensate for a storage path that still constrains each iSCSI flow to one physical link.

Topics: VMware vSphere, ESXi, iSCSI, NFS, LACP, MPIO, 10GbE, storage architecture

Key distinction

LACP increases aggregate network capacity across multiple flows. MPIO creates and manages multiple storage paths. They solve different problems, and an LACP bundle does not replace VMware iSCSI multipathing.

1. Storage performance is an end-to-end system

In a VMware vSphere environment, storage performance is not determined only by the media inside the host or NAS. The final result depends on every layer between the virtual machine and the storage backend.

Virtual Machine
      ↓
Storage Protocol
      ↓
Network
      ↓
Storage Path Design
      ↓
NAS/SAN Controller
      ↓
Cache
      ↓
RAID / Storage Media

This article compares three common VMware storage models:

Local VMFS storage
NFS datastore
iSCSI datastore

It also explains how 8×1GbE LACP, 10GbE, iSCSI MPIO, and NVMe SSD cache affect different parts of that path.

2. VMware storage types compared

Local VMFS storage

Local storage uses disks installed directly in the ESXi host.

VM
 ↓
VMDK
 ↓
VMFS
 ↓
Local SSD / NVMe / RAID

Advantages:

Lowest latency
Highest single-host performance
Simple configuration

Limitations:

Storage is bound to one ESXi host
Shared-storage capability is limited
It is not ideal for multi-host HA clusters

NFS datastore

NFS provides file-based storage from a NAS.

ESXi
 ↓
NFS Client
 ↓
Network
 ↓
NAS File System

Advantages:

Simple deployment
Easy capacity expansion
Shared access between ESXi hosts
Good compatibility with NAS platforms

NFS is often preferred for homelabs, small VMware clusters, and straightforward shared-storage requirements.

iSCSI datastore

iSCSI provides block storage to ESXi.

ESXi
 ↓
iSCSI Initiator
 ↓
LUN
 ↓
VMFS
 ↓
Virtual Machines

Advantages:

Block-level storage
VMFS support
Mature multipathing capability
Enterprise SAN-style architecture

Limitations:

More complex configuration
Requires a correct path design

Feature	Local VMFS	NFS	iSCSI
Storage type	Block	File	Block
Shared storage	No	Yes	Yes
VMFS	Yes	No	Yes
Configuration	Easy	Easy	Complex
HA / vMotion suitability	Limited	Good	Good
MPIO	No	Not traditional block MPIO	Yes
Enterprise SAN model	Low	Medium	High

3. Why 8×1GbE LACP is not one 8Gbps link

A common assumption is that combining eight 1GbE interfaces creates a single 8Gbps connection. LACP does not work that way. It distributes network flows across the physical members of a bundle.

Flow A → NIC1 → 1Gbps
Flow B → NIC2 → 1Gbps
Flow C → NIC3 → 1Gbps

Total aggregate bandwidth can increase when there are multiple suitable flows, but each member remains a 1GbE interface.

8×1GbE LACP provides multiple 1GbE paths. It does not create one 8GbE interface for a single flow.

The 10GbE advantage

A 10GbE interface provides up to 10Gbps on one physical path. This is materially different from distributing traffic across multiple 1GbE members.

Feature	8×1GbE LACP	10GbE
Aggregate bandwidth	High across multiple flows	Higher
Single-flow performance	Limited by a member link	Much stronger
Cabling	Complex	Simpler
Port usage	High	Low
Management	More complex	Easier

For storage vMotion, VM cloning, backup, and large sequential I/O, 10GbE usually provides a better operational experience.

4. What NVMe SSD cache can and cannot improve

Modern NAS platforms often use NVMe SSD cache in front of HDD RAID.

VMware
  ↓
NFS / iSCSI
  ↓
Network
  ↓
NAS Controller
  ↓
NVMe Cache
  ↓
HDD RAID

NVMe cache can improve random IOPS, storage latency, small-block workloads, and concurrency across multiple virtual machines. It is particularly useful for VM operating system disks, databases, logs, and random read/write workloads.

It cannot bypass a network bottleneck. If the NAS can process more than 1GB/s internally but VMware reaches it through 1GbE, actual throughput remains constrained to roughly the capacity of that network path.

5. LACP and MPIO operate at different layers

Technology	Primary purpose	What it handles
LACP	Network link aggregation	Ethernet links, network flows, and link redundancy
MPIO	Storage path multipathing	iSCSI paths, storage I/O distribution, failover, and load balancing

LACP ≠ MPIO.

A working LACP bundle can provide network redundancy and aggregate capacity while the VMware storage stack still sees only one usable iSCSI path.

6. Correct iSCSI MPIO design

An LACP connection between ESXi, the switch, and the NAS does not by itself create multiple VMware storage paths.

ESXi
  |
LACP
  |
Switch
  |
NAS
  |
iSCSI

A multipath design presents independent paths to the storage stack:

vmnic1 → vmk1 → iSCSI Path 1
vmnic2 → vmk2 → iSCSI Path 2
vmnic3 → vmk3 → iSCSI Path 3

Multiple Paths
      ↓
VMware NMP
      ↓
Round Robin

Each path becomes visible to VMware Native Multipathing, allowing the configured path-selection policy to distribute I/O and provide failover.

7. Case study: 8×1GbE LACP iSCSI remained near 1GbE

Initial design

A VMware server and NAS both used multiple 1GbE interfaces in the following design:

ESXi
8×1GbE
  ↓
LACP
  ↓
Switch
  ↓
LACP
  ↓
NAS
  ↓
iSCSI

The expected result was 8Gbps of aggregate storage bandwidth. Actual performance remained close to a single 1GbE link.

Root cause

The problem was not a bad cable, a failed LACP bundle, the NAS, or the disks. The issue was architectural: the iSCSI session was still subject to flow distribution over individual LACP members.

iSCSI Flow
    ↓
LACP Hash
    ↓
One 1GbE Member
    ↓
≈100MB/s

The environment had network aggregation, but it did not have storage multipathing.

8. Recommended architectures

When existing hardware is limited to 1GbE

Separate normal workload traffic from storage traffic, and use independent interfaces for independent iSCSI paths.

Work network:
2×1GbE → LACP

Storage network:
NIC1 → iSCSI Path 1
NIC2 → iSCSI Path 2
NIC3 → iSCSI Path 3
NIC4 → iSCSI Path 4
           ↓
          MPIO

For a new deployment

Use independent 10GbE storage paths, ideally through separate switching paths where the availability design requires it.

10GbE Path A → Switch A → Storage
10GbE Path B → Switch B → Storage

MPIO + independent storage paths

9. Final recommendations

Scenario	Recommended design
Single ESXi host	Local SSD or NVMe
Simple VMware shared storage	NFS + 10GbE
NAS with HDD and VM workloads	NVMe cache + 10GbE
iSCSI with existing 1GbE	Independent NICs + MPIO
Enterprise iSCSI	10GbE + MPIO
New VMware cluster	Dual 10GbE storage paths

Conclusion

LACP improves network aggregation. MPIO improves storage path utilization. They solve different problems.

A faster NAS with NVMe cache cannot overcome a poor network design, and a large number of 1GbE ports does not automatically become one high-speed iSCSI path.

Predictable VMware storage performance requires the storage protocol, network design, independent paths, multipathing policy, and storage backend to be designed as one system.

5 GHz Wi-Fi Channel Planning in Metal-Heavy Industrial Environments

Frank Zhang — Tue, 01 Sep 2026 10:56:16 +0000

5 GHz Wi-Fi Channel Planning and Interference Optimization in Metal-Intensive Industrial Environments

In enterprise wireless design, two assumptions often lead to poor results: wider channels must provide better performance, and higher AP transmit power must provide better coverage.

Those assumptions may be acceptable in some small home networks, but they do not translate well to factories, warehouses, production floors, and other complex RF environments. When a site contains large amounts of metal, dense AP deployments, and mobile clients, using 80 MHz or even 160 MHz channels indiscriminately can reduce overall WLAN stability rather than improve it.

This article uses a typical Wi-Fi 6 deployment in a manufacturing plant to examine the relationship between 5 GHz channel width, co-channel contention, channel reuse, and transmit power, and to explain why narrower channels are often the better engineering choice in industrial environments.

1. Scenario: A Wi-Fi 6 Network on a Manufacturing Floor

Consider a large mechanical manufacturing plant running an IEEE 802.11ax (Wi-Fi 6) wireless network. The WLAN primarily serves barcode scanners, PDAs, industrial tablets, and mobile inspection devices.

The production floor contains metal-processing equipment, steel columns, production lines, machinery, and other reflective surfaces. As a result, RF propagation is affected by reflection, scattering, shadowing, and multipath.

During the initial deployment, the 5 GHz radios were configured to use 80 MHz channel bonding in order to maximize available throughput.

From a purely theoretical perspective, this configuration is understandable. Wider channels can provide higher PHY rates and greater peak throughput for an individual client under suitable conditions.

After the WLAN went into production, however, several problems appeared:

Some mobile clients experienced intermittent disconnections.
PDA connectivity became unstable while moving through the facility.
Wireless latency fluctuated noticeably.
Actual throughput varied significantly over time.

A subsequent RF survey and interference analysis showed substantial overlap between neighboring APs operating on the same channel. In practical terms, the WLAN was suffering from excessive co-channel contention, commonly discussed under the broader term Co-Channel Interference (CCI).

At this point, the key question was no longer whether the Wi-Fi signal was strong enough. The more important question became:

Was the existing channel plan appropriate for the AP density and RF characteristics of the site?

2. Why 80 MHz Channels Can Increase Contention

Wi-Fi channel width is fundamentally a trade-off between peak per-link throughput and frequency reuse.

A 20 MHz channel consumes a relatively small portion of spectrum, making it possible to create more independent channel assignments. A 40 MHz channel combines two 20 MHz channels, while 80 MHz and 160 MHz channels

As channel width increases, an individual AP may gain a higher theoretical maximum data rate. At the same time, however, fewer independent channel combinations remain available for neighboring APs.

In a home network with only one or two access points, this trade-off may have little practical impact. In a factory, school, hospital, warehouse, or large office, dozens of APs may operate within the same RF environment.

If many of those APs use 80 MHz channels, the number of practical channel reuse options decreases quickly. Nearby APs are therefore more likely to share the same channel or occupy overlapping spectrum.

That increases contention and reduces the amount of airtime available to each AP and its associated clients.

For enterprise WLAN design, channel planning should therefore focus on the efficiency of the entire RF system, not just the theoretical capability of a single access point.

3. How Co-Channel Contention Affects Wi-Fi Performance

When nearby APs operate on the same channel and can hear one another, their clients effectively compete for access to the same RF medium.

Unlike a switched full-duplex Ethernet network, IEEE 802.11 uses a shared-medium access mechanism. Devices must determine whether the channel is available before transmitting and may need to defer or back off when other transmissions are detected.

As the number of APs and clients sharing the same channel increases, the network may experience:

More airtime contention
Longer transmission wait times
Increased backoff
Higher retry rates
Lower effective throughput
Greater latency and jitter

This is why co-channel problems are often difficult to identify from a simple signal-strength indicator.

The WLAN may not fail completely. Clients may remain associated, and the signal level may appear strong, while application performance becomes inconsistent.

A device can therefore show a strong Wi-Fi signal and still deliver a poor user experience if the channel is heavily utilized or the RF environment contains excessive co-channel contention.

4. Why Metal-Intensive Industrial Environments Are More Difficult

A factory floor is significantly different from a typical office.

In an office, RF propagation is mainly influenced by walls, furniture, partitions, and people. In a manufacturing plant, large machinery, steel structures, production lines, racks, and other conductive surfaces can create substantial reflection and multipath propagation.

A transmitted signal may reach a client through several paths rather than one direct path. Modern Wi-Fi technologies such as OFDM and MIMO are designed to operate in multipath environments and can sometimes make productive use of them.

However, that does not mean that more reflections automatically improve wireless performance.

When complex multipath propagation is combined with dense AP placement and poor channel reuse, the RF environment becomes much harder to predict and optimize. A client may hear several APs at usable signal levels, while multiple cells compete for airtime on the same channel.

For that reason, the design objective in an industrial WLAN should rarely be the highest possible PHY rate. More practical priorities usually include:

Stable connectivity
Low retry rates
Predictable latency
Reliable roaming
Sufficient application throughput

This distinction is particularly important for barcode scanners, PDAs, and mobile inspection terminals.

These devices often do not require hundreds of megabits per second of sustained throughput. What they need is a reliable link, consistent latency, low packet loss, and smooth handoff between APs.

5. A Better Optimization Strategy: Reduce Channel Width

Once excessive co-channel contention has been confirmed, the more appropriate response is usually not to make the channel wider. Instead, channel width should be reduced where necessary.

For example, APs configured for 80 MHz operation can be moved to 40 MHz. In particularly dense areas, 20 MHz channels may be more appropriate.

This reduces the peak theoretical rate available to a single AP, but it creates more opportunities for independent channel assignments.

With more channels available for reuse, neighboring APs can be separated more effectively in the frequency domain, while APs that must reuse the same channel can be placed farther apart in the physical topology.

This is the principle of channel reuse.

Channel reuse does not mean that every AP across an entire plant must use a unique channel. In a sufficiently large WLAN, that would be unrealistic.

The actual goal is to ensure that APs reusing the same channel are separated enough that their coverage areas and contention domains are kept under reasonable control.

Reducing channel width is therefore not simply a decision to “accept lower speed.” It is a deliberate trade-off: part of the theoretical peak throughput of an individual AP is exchanged for better spectrum reuse and more predictable system-wide performance.

In many enterprise WLANs, that is the better engineering decision.

6. Why 160 MHz Is Usually Not the Answer

A common reaction to unstable 80 MHz performance is to assume that moving to 160 MHz will solve the problem by increasing available bandwidth.

In a dense WLAN, the opposite may happen.

A 160 MHz channel consumes a much larger portion of the available 5 GHz spectrum. This leaves fewer independent channel assignments and forces more aggressive channel reuse.

As a result, neighboring APs are more likely to contend for the same airtime, especially in deployments with high AP density.

For this reason, 160 MHz operation is generally more appropriate for environments where AP density is relatively low, the RF environment is clean, compatible spectrum is available, and very high per-client throughput is genuinely required.

It should not be treated as a default setting for factories, warehouses, hospitals, schools, or dense enterprise offices.

Channel width must be selected according to the actual RF design and application requirements, not simply by choosing the largest value supported by the hardware.

7. Why Maximum AP Transmit Power Can Make Things Worse

Another common troubleshooting response is to increase the transmit power of every AP.

At first glance, this seems reasonable: if users are experiencing connectivity problems, stronger AP transmissions should improve coverage.

In a multi-AP enterprise WLAN, however, excessive transmit power can enlarge cell sizes and increase overlap between neighboring APs.

That may create several additional problems:

More co-channel contention
Larger interference and contention domains
Less predictable roaming boundaries
Sticky-client behavior
Uplink/downlink asymmetry

The last point is particularly important.

An enterprise AP may be capable of transmitting at considerably higher power than a PDA, phone, or handheld scanner. A client may therefore be able to hear the AP from a long distance while lacking enough transmit power to provide a similarly strong return path.

The result can be misleading: the client displays a strong Wi-Fi signal, but the bidirectional link performs poorly.

For this reason, enterprise WLAN design should focus on controlling cell size rather than simply maximizing AP transmit power.

8. Wi-Fi 6 Does Not Eliminate the Need for RF Planning

Wi-Fi 6 introduced several important mechanisms intended to improve efficiency in dense environments, including OFDMA, MU-MIMO, BSS Coloring, Spatial Reuse, and Target Wake Time.

BSS Coloring, for example, helps devices distinguish transmissions from their own BSS from those belonging to neighboring BSSs, which can improve spatial reuse under suitable conditions.

These capabilities are valuable, but they do not compensate for fundamentally poor RF design.

If a deployment has excessive AP density, inappropriate channel widths, poor channel reuse, overly high transmit power, or badly chosen AP locations, upgrading to Wi-Fi 6 does not automatically remove those problems.

Protocol-level improvements can make more efficient use of available spectrum.

They cannot create additional spectrum.

RF planning therefore remains a fundamental part of WLAN design, regardless of the Wi-Fi generation in use.

9. A More Practical Industrial Wi-Fi Design Process

A well-designed industrial WLAN should begin with application requirements rather than AP configuration.

The first step is to understand the client devices and the traffic they actually generate. Barcode scanners, PDAs, and industrial mobile devices often value low latency, roaming stability, and packet delivery consistency far more than maximum download speed.

The next step is an RF survey that evaluates AP placement, structural obstacles, reflective surfaces, attenuation, coverage overlap, and actual client behavior.

Only then should channel width, channel reuse, and transmit power be finalized.

A practical workflow may look like this:

Application requirements → RF survey → AP placement → channel-width planning → channel reuse → transmit-power tuning → roaming validation → ongoing monitoring and adjustment

This process is more reliable than attempting to solve an industrial wireless problem by changing a single radio parameter in isolation.

10. Metrics That Matter During Troubleshooting

When troubleshooting this type of WLAN problem, signal bars alone are not enough.

RSSI and SNR remain useful indicators of received signal quality, but they should be evaluated together with other RF and client metrics, including:

Channel Utilization — how much of the available airtime is already occupied
Retry Rate — whether frames are being retransmitted frequently
CCA Busy Time — how often the radio senses the channel as busy
Roaming Events — whether mobile clients transition between APs as expected
PHY Rate vs. Actual Throughput — whether high negotiated rates translate into usable application performance

If RSSI is acceptable but channel utilization and retry rates remain high, the problem may be related to contention or channel design rather than insufficient coverage.

It is also important to distinguish between PHY rate and real application throughput.

A reported wireless link rate of 1200 Mbps or 2400 Mbps is not equivalent to application-layer throughput. Protocol overhead, contention, retransmissions, client capability, channel conditions, and medium sharing all reduce the usable rate.

For many enterprise and industrial applications, a stable and predictable connection is more valuable than a much higher peak rate that fluctuates significantly.

11. Recommended Direction for This Scenario

Returning to the original manufacturing-floor scenario, the following conditions have already been identified:

The WLAN operates in the 5 GHz band.
The infrastructure uses Wi-Fi 6.
Multiple APs are deployed in the same facility.
The current channel width is 80 MHz.
Neighboring APs exhibit significant co-channel contention.
Mobile clients experience disconnections and unstable throughput.

Under these conditions, the most appropriate optimization direction is to:

Reduce the channel width from 80 MHz to 40 MHz or, where AP density requires it, 20 MHz; increase the number of practical channel assignments; and redesign channel reuse according to the physical AP layout and measured RF conditions.

In the original multiple-choice scenario, this corresponds to Option A.

Increasing the channel width to 160 MHz would further reduce channel-planning flexibility. Setting every AP to maximum transmit power could increase cell overlap and contention. Moving the entire WLAN to 2.4 GHz would introduce a different set of limitations, including substantially less channel capacity and typically higher congestion.

None of those approaches addresses the underlying problem as directly as improved 5 GHz channel planning.

Conclusion

Enterprise Wi-Fi design is not about maximizing the performance of a single access point.

A production WLAN must balance channel width, AP density, channel reuse, transmit power, client behavior, roaming requirements, regulatory constraints, and the physical RF environment.

In dense offices, warehouses, and metal-intensive industrial facilities, using 20 MHz or 40 MHz channels should not be interpreted as an outdated or low-performance design.

In many cases, narrower channels are a deliberate engineering choice that trades some theoretical per-AP peak throughput for more reusable spectrum, lower co-channel contention, more predictable roaming, and greater overall WLAN stability.

The most important principle is simple:

The goal of Wi-Fi optimization is not to make one AP as fast as possible. It is to make the entire wireless system stable, efficient, and predictable.

Cisco and Huawei STP Interoperability in Industrial Networks: A Practical VBST Approach

Frank Zhang — Mon, 31 Aug 2026 05:58:32 +0000

In industrial network upgrades, a very common situation is that the existing core network has been running on Cisco switches for years, while newly added production lines, PLC cabinets, industrial PCs, or monitoring devices may use Huawei switches due to procurement cycles, cost considerations, or supply-chain constraints.

In this kind of environment, the real challenge is often not VLAN configuration, but Spanning Tree Protocol interoperability.

A Typical Industrial Network Scenario

Consider a manufacturing workshop where the existing network is based on Cisco switches:

                Cisco Core-1
                      │
              ┌───────┴───────┐
              │               │
          Cisco SW         Cisco SW
                              │
                        ┌─────┴─────┐
                        │           │
                    Huawei SW ===== Huawei SW
                        │           │
                    PLC / HMI   Industrial PCs / Cameras

To improve production network availability, redundant links may exist between the two workshop switches and between the access layer and the core network.

The workshop may also use multiple VLANs:

VLAN 10   PLC Control Network
VLAN 20   HMI / SCADA Network
VLAN 30   Industrial Computers
VLAN 40   Video Surveillance
VLAN 99   Network Management

If the existing Cisco core is running PVST+ or Rapid PVST+, simply configuring standard MSTP on the newly added Huawei switches requires careful consideration of how the two spanning-tree mechanisms interact.

Why VBST Can Be a Better Fit

One of the defining characteristics of Cisco PVST/PVST+ is:

Each VLAN can have its own independent spanning-tree instance.

For example:

VLAN 10 → STP Instance 10
VLAN 20 → STP Instance 20
VLAN 30 → STP Instance 30

This means that different VLANs can even use different forwarding paths.

Huawei switches that support VBST (VLAN-Based Spanning Tree) can follow a similar model by creating independent spanning-tree instances for individual VLANs.

On switch models and software versions that support the required functionality, VBST can be used to interoperate with Cisco PVST+/Rapid PVST+ networks.

This allows newly introduced Huawei switches to preserve the spanning-tree design logic of the existing Cisco network as much as possible, without forcing a redesign of the entire core STP architecture just to accommodate a few new access switches.

Conceptually, the relationship can be viewed like this:

Cisco                           Huawei
PVST+/Rapid PVST+               VBST
        │                         │
        ├── VLAN 10 STP ──────────┤
        ├── VLAN 20 STP ──────────┤
        └── VLAN 30 STP ──────────┤

For industrial networks that have been operating reliably for many years, this is important.

The first principle of expansion is usually not to adopt the newest architecture, but to minimize the impact on the existing production network.

Why You Should Not Automatically Choose MSTP

MSTP is, of course, a mature and standardized protocol, and it is well suited to large-scale networks.

Its design philosophy, however, is different:

Multiple VLANs
      ↓
Mapped to a smaller number of MST Instances

For example:

VLAN 10, 20 → MSTI 1
VLAN 30, 40 → MSTI 2

Cisco PVST+, on the other hand, is closer to:

One VLAN
    ↓
One STP Instance

Therefore, when adding new switches to an existing Cisco PVST+/Rapid PVST+ network, configuring the new devices directly with MSTP does not necessarily mean the network will fail.

However, the spanning-tree behavior at the boundary, root bridge election, and blocked forwarding paths for different VLANs all require additional validation.

In a production environment where PLCs, robots, MES terminals, and other industrial systems are already online, changes like this should be handled very carefully.

What Matters Most During Industrial Network Deployment

Protocol compatibility is only the first step.

For example, suppose the original network design specifies:

Cisco Core-1
     ↓
VLAN 10 Root Primary
VLAN 20 Root Primary
VLAN 30 Root Primary

After introducing Huawei switches, you must make sure that an inappropriate default STP priority does not cause an access-layer switch in the workshop to unexpectedly become the Root Bridge.

At minimum, the following should be verified:

Is the Root Bridge still located at the core layer?
        ↓
Does the STP topology for each VLAN match the design?
        ↓
Are redundant links correctly placed into Blocking/Discarding state?
        ↓
Can the network converge quickly after the primary link fails?
        ↓
After the link is restored, are there any loops or excessive MAC flapping events?

In an industrial environment, I strongly recommend performing an actual link-failure test:

Normal Operation
      ↓
Disconnect the Primary Uplink
      ↓
Observe the Backup Link Take Over
      ↓
Check PLC / HMI Communication
      ↓
Restore the Primary Link
      ↓
Check STP, MAC Address Tables, and Application Status Again

In an office network, a network interruption lasting several seconds may simply feel like a slow-loading webpage.

In a production network, however, it may result in HMI disconnections, PLC communication alarms, or even production interruptions.

A More Practical Design Principle

For a mixed Cisco and Huawei industrial network, the design principle can be summarized in one sentence:

Keep the core unchanged and make the edge compatible. First ensure consistent spanning-tree behavior, then consider architecture standardization later.

If an existing Cisco PVST+/Rapid PVST+ network has already been running reliably, and the requirement is simply to add several Huawei switches that support VBST, using VBST to continue the existing Per-VLAN STP design can often introduce less risk than immediately migrating the entire production network to a different spanning-tree architecture.

When the core switching infrastructure is eventually replaced, the network can then be redesigned in a more systematic way using technologies such as MSTP, stacking, MLAG, or other redundancy architectures.

The most important principle in industrial network upgrades is not that newer protocols are always better.

It is to:

maintain compatibility with the existing network, control the scope of change, and ensure that the failure of any single link does not disrupt production.

Note: VBST support and interoperability with Cisco PVST+/Rapid PVST+ depend on the specific Huawei switch model, VRP software version, and interface configuration. Before deploying this design in a production environment, verify support for the actual hardware and software versions being used, and validate the STP root bridge, trunk VLANs, and link-failover behavior in a test environment.

Why a Windows 11 VM Shows Nearly 100% Memory Usage in Proxmox VE

Frank Zhang — Fri, 28 Aug 2026 03:27:35 +0000

A Windows 11 VM in Proxmox VE was showing nearly 100% memory usage in monitoring.

Inside Windows Task Manager, however, actual memory usage was only around 30–50%.

At first glance, that looks like a monitoring problem.

It wasn't.

The issue was in the VM configuration: the PVE Ballooning Device had been disabled, which meant Proxmox VE was not receiving the guest memory statistics needed to reflect the actual Windows memory state.

I encountered this while monitoring a Proxmox VE environment with OpsHome NOC.

This post documents how I traced the discrepancy and fixed it.

The symptom

On the same Proxmox VE host, the memory usage of Ubuntu VMs looked normal.

One Windows 11 VM was different.

The VM had 24 GB of RAM configured, but the monitoring result remained close to:

Memory: 100%
Used: about 24.2 GB
Total: 24 GB

Inside Windows 11 Task Manager, however, the VM was clearly not using all of its memory.

The difference looked roughly like this:

Monitoring: 90%–100%
Windows 11: 30%–50%

That is too large a difference to treat as a normal sampling variation.

If you encounter something similar, especially when Linux VMs on the same Proxmox host look normal, do not immediately assume:

Windows has a memory leak
The monitoring threshold is wrong
The monitoring application is calculating memory incorrectly

The more important question is:

Is Proxmox VE actually receiving the correct memory statistics from the Windows guest?

Checking BalloonService inside Windows 11

For Proxmox VE to obtain useful guest memory statistics from a Windows VM, the VirtIO Balloon driver and its related Windows service need to be available.

Inside Windows 11, I opened PowerShell and checked BalloonService:

Get-Service *balloon*

The result showed:

Running  BalloonService

So the Windows-side BalloonService was already installed and running.

At this point, the guest-side service did not appear to be the problem.

The next step was to check the VM configuration on the Proxmox side.

Checking the Proxmox VE configuration

On the PVE host, I checked the VM memory configuration.

In this example, the VM ID is 100:

qm config 100 | grep -E '^(memory|balloon):'

The result was:

balloon: 0
memory: 24576

That was the key clue.

balloon: 0 means the Ballooning Device is disabled for the VM.

So the situation was effectively:

Windows 11
    ↓
VirtIO BalloonService running
    ↓
PVE Ballooning Device disabled
    ↓
Guest memory statistics path incomplete
    ↓
PVE memory information does not reflect
the actual Windows memory state
    ↓
Monitoring receives that upstream data

The monitoring software was not the root cause.

The VM configuration was incomplete.

Why this can be confusing

This issue is easy to misdiagnose because Windows itself can continue operating normally.

For example:

Windows boots normally
Applications work normally
Network works normally
Disk works normally

There may be no obvious guest OS failure.

The problem only becomes visible when you compare:

Windows Task Manager
vs.
Proxmox VE memory statistics
vs.
Monitoring data

That makes Ballooning configuration easy to overlook.

It is especially relevant for Windows VMs that have been migrated from another virtualization platform.

This VM had been migrated

VM migration is one situation where I would check Ballooning early.

When migrating a Windows VM from environments such as:

VMware
ESXi
Hyper-V
another Proxmox configuration

we usually spend most of our time checking:

CPU
VirtIO drivers
Disk controller
Network adapter
EFI
TPM
QEMU Guest Agent

Memory Ballooning may not get the same attention.

If Ballooning was disabled during migration or while tuning the VM, Windows can continue working normally while guest memory reporting becomes misleading.

Fixing the Ballooning configuration

In the Proxmox VE Web UI, open:

VM
→ Hardware
→ Memory
→ Edit

Then enable:

Ballooning Device

There is an important distinction here.

Enabling the Ballooning Device does not necessarily mean you have to let Proxmox dynamically reduce the amount of memory available to the Windows VM.

If you want the Windows 11 VM to continue using a fixed amount of RAM, you can set the maximum and minimum memory to the same value.

For this 24 GB VM, I used:

Memory: 24576 MiB
Minimum Memory: 24576 MiB
Ballooning Device: enabled

This preserves the fixed 24 GB memory allocation while enabling the Ballooning Device needed for the guest memory statistics path.

Command-line configuration

The same configuration can also be applied from the PVE command line.

For VM 100 with 24 GB RAM:

qm set 100 --balloon 24576

After changing the setting, verify it again:

qm config 100 | grep -E '^(memory|balloon):'

The important point is that it should no longer show:

balloon: 0

Fully shut down the Windows VM

After changing the Ballooning configuration, I fully shut down the Windows 11 VM and then started it again.

I did not rely only on an in-guest Windows restart.

The Ballooning Device is part of the VM's virtual hardware configuration, so a full stop and start is the safer approach.

The sequence was:

Shut down Windows 11
        ↓
Confirm the VM is stopped in PVE
        ↓
Start the VM again

Verifying Guest Memory Statistics

After Windows 11 started again, I first checked the VM configuration:

qm config 100 | grep -E '^(memory|balloon):'

Then I queried the current VM status through Proxmox VE:

pvesh get /nodes/PVE02/qemu/100/status/current \
  --output-format json-pretty

Useful memory-related fields to look for include:

balloon
ballooninfo
free_mem
total_mem

The exact output may vary depending on your Proxmox VE version and VM configuration.

The important point is that guest memory information should now be available instead of the VM effectively being represented only by its allocated memory.

What changed after the fix?

Before fixing the Ballooning configuration, the situation looked approximately like this:

Windows 11 Task Manager: ~40%
Monitoring:              ~100%

After restoring the Ballooning configuration and restarting the VM, the monitoring value gradually returned to a reasonable range:

Windows 11 Task Manager: ~40%
Monitoring:              ~40%

The values do not have to match exactly every second or every percentage point.

Small differences are normal.

There are several reasons:

Different sampling intervals
Windows memory accounting
Cached memory
Available memory
Timing differences between the guest and hypervisor
Monitoring collection intervals

The important result is not exact percentage equality.

The important result is that the VM no longer remains incorrectly stuck near 100%.

Why Ubuntu VMs looked normal

One clue in this case was that Ubuntu VMs on the same Proxmox VE host were reporting reasonable memory usage.

Only the Windows 11 VM looked abnormal.

That suggested the problem was unlikely to be a global PVE monitoring failure.

Instead, it pointed toward something specific to the Windows VM or its guest-to-hypervisor statistics path.

That is why comparing multiple VMs on the same host can be useful during troubleshooting.

If you see:

Ubuntu VM: normal
Ubuntu VM: normal
Windows 11 VM: nearly 100%

while Task Manager shows much lower usage, checking the Windows Ballooning configuration is a good next step.

When should you check Ballooning first?

I would check Ballooning relatively early when several of these conditions are present:

A Windows VM stays at 90–100% memory usage.
Windows Task Manager shows substantially lower memory usage.
Linux VMs on the same PVE host look normal.
The Windows VM was migrated from VMware, ESXi, Hyper-V or another platform.
VM memory settings were manually adjusted.
Ballooning was intentionally disabled to keep memory fixed.
BalloonService is installed and running inside Windows.
QEMU Guest Agent is working, but memory statistics still look unreasonable.

A configuration such as this deserves particular attention:

balloon: 0
memory: 24576

especially when it appears together with a large difference between Windows Task Manager and PVE-based monitoring.

QEMU Guest Agent is not the same thing as BalloonService

Another useful distinction is that QEMU Guest Agent and the VirtIO Balloon driver are related to guest integration, but they are not the same component.

It is possible to have:

QEMU Guest Agent: working
BalloonService: running
Ballooning Device: disabled

and still have misleading memory statistics.

So when troubleshooting this issue, checking only QEMU Guest Agent is not enough.

The Ballooning configuration itself also needs to be verified.

Fixed memory and Ballooning are not mutually exclusive

One reason people disable Ballooning is that they want the VM to always have a fixed amount of memory.

That requirement is reasonable.

But disabling the Ballooning Device entirely can also affect the guest memory statistics path.

For a VM that should always remain at 24 GB, a more useful configuration is:

Maximum Memory: 24576 MiB
Minimum Memory: 24576 MiB
Ballooning Device: enabled

Conceptually:

Minimum = Maximum

means Proxmox does not have a lower memory target to reclaim toward.

At the same time, the Ballooning Device remains present for the Windows guest integration path.

The complete troubleshooting chain

The final troubleshooting process was:

Windows 11 shows normal memory usage
        ↓
Monitoring shows nearly 100%
        ↓
Compare other VMs on the same PVE host
        ↓
Ubuntu VM memory looks normal
        ↓
Check Windows BalloonService
        ↓
BalloonService is running
        ↓
Check PVE VM configuration
        ↓
Find balloon: 0
        ↓
Enable Ballooning Device
        ↓
Set minimum memory = maximum memory
        ↓
Fully stop and start Windows 11
        ↓
Check PVE Guest Memory Statistics
        ↓
Observe monitoring again

The monitoring software was not the root cause

This is the main lesson from the troubleshooting case.

OpsHome NOC was displaying the memory information available through the Proxmox VE monitoring path.

The root cause existed upstream.

The actual chain was:

PVE Ballooning Device disabled
        ↓
Guest Memory Statistics incomplete
        ↓
PVE memory information differs from
the actual Windows memory state
        ↓
Monitoring receives the PVE data
        ↓
Windows VM appears close to 100%

So when monitoring information clearly conflicts with what you see inside a guest operating system, it is worth checking the entire data path before concluding that the monitoring application is calculating incorrectly.

For a virtualized workload, that path looks roughly like:

Guest OS
   ↓
Guest drivers and services
   ↓
Hypervisor
   ↓
Hypervisor API / statistics
   ↓
Monitoring

Every downstream layer depends on the quality of the data provided by the layer before it.

Final checklist

If a Windows 11 VM appears to use nearly 100% memory in Proxmox VE monitoring while Task Manager says otherwise, try this checklist:

1. Check Windows Task Manager
        ↓
2. Confirm the actual guest memory usage
        ↓
3. Check BalloonService in Windows
        ↓
4. Run:
   qm config <VMID>
        ↓
5. Look for balloon: 0
        ↓
6. Enable the Ballooning Device
        ↓
7. If fixed RAM is required,
   set minimum memory = maximum memory
        ↓
8. Fully shut down the VM
        ↓
9. Start the VM again
        ↓
10. Verify Guest Memory Statistics in PVE
        ↓
11. Observe the monitoring data again

For example:

Get-Service *balloon*

Then on Proxmox VE:

qm config 100 | grep -E '^(memory|balloon):'

And after fixing the configuration:

pvesh get /nodes/PVE02/qemu/100/status/current \
  --output-format json-pretty

Conclusion

In this case, the Windows 11 VM was not actually consuming all 24 GB of its memory.

The near-100% value was the result of an incomplete memory statistics path between the Windows guest and Proxmox VE.

The key configuration was:

balloon: 0

After enabling the Ballooning Device, keeping minimum and maximum memory equal, fully stopping and starting the Windows VM, and verifying the guest memory statistics, the reported memory usage returned to a reasonable range.

The main takeaway is simple:

Before blaming the monitoring layer, verify that the hypervisor is receiving the data you expect from the guest.

This is especially worth remembering after migrating Windows virtual machines between hypervisors.

This troubleshooting case was originally documented while monitoring a Proxmox VE environment with OpsHome NOC.

Original article:

https://docs.opshome.run/articles/opshome-noc-pve-windows-ballooning-memory-monitoring.html

FortiGate Already Has Powerful Management Tools—So Why Do I Still Want a Simpler Status View?

Frank Zhang — Wed, 26 Aug 2026 12:16:27 +0000

When maintaining FortiGate devices on a daily basis, what I do most often is not change configurations, but first check the current device status. For example, if someone at a remote site reports that the network has become slow, or if a WAN link has just experienced a fluctuation, I usually do not immediately start changing configurations. Instead, I first take a look at the current state of the device.

Is the device online? Is the WAN link healthy? Is there anything unusual in the upstream or downstream traffic? Have any interfaces gone down? How are CPU and memory utilization looking? Has the Session count changed significantly compared with normal levels? In most cases, after checking these basic indicators, I already have a fairly good idea of where to look next.

The FortiGate management console can provide all of this information. But sometimes I am not trying to change configuration parameters, nor do I need to enter the full management workflow right away. I simply want to get a quick understanding of the device’s current operating status.

NOC for FGT started from this very specific need.

Being Able to Log In Does Not Mean You Understand the Device Status

FortiGate’s Web GUI is very comprehensive. System status, interfaces, routing, VPN, firewall policies, logs, and various security features can all be managed from within it.

If I need to modify policies, check routing, or adjust configurations, opening the full management interface makes perfect sense. But if someone simply tells me, “Something seems wrong with the network at this site,” the first step is usually not to change anything. Instead, I first check a few basic indicators such as CPU, Memory, WAN, Interface, and Session status.

These indicators may be basic, but they often determine the direction of the troubleshooting process. If the WAN link is already down, the problem may not be related to the firewall policy at all. If the interfaces look normal but CPU utilization or Session counts suddenly change significantly, then device load and current traffic should be investigated further. If none of these indicators show anything unusual, I can then gradually expand the scope of troubleshooting to DNS, the upstream network, clients, or the applications themselves.

For this reason, the first step in many network troubleshooting situations is not changing configurations, but observing the current operating state of the device. I first try to understand what is happening, and then decide whether I need to move on to the CLI, review logs, or inspect specific configurations.

This is also where I started thinking about the information density of NOC for FGT.

FortiManager, FortiAnalyzer, and NMS Platforms Already Exist. Why Another Tool?

FortiManager, FortiAnalyzer, as well as systems such as Zabbix, PRTG, Prometheus, and Grafana, all have clearly defined purposes and solve network management problems at different scales and levels.

If you need to manage a large number of FortiGate devices, centrally configure policies, retain logs over the long term, analyze historical trends, or build a complete monitoring system for an entire infrastructure, these platforms are clearly more suitable. I have no intention of building another NMS, nor did I design NOC for FGT as a smaller version of FortiManager.

The problem I actually want to solve is much smaller than the problems those platforms are designed to address: I simply want to quickly check how a particular FortiGate is doing right now.

A complete management platform is concerned with the question, “How should the entire network be managed?” In day-to-day operations, however, sometimes I only need to answer a much more specific question: “Is there anything about this particular device that needs my attention right now?”

Both needs fall under network management, but their usage scenarios are different.

For large enterprise environments, centralized management and monitoring platforms remain essential. But for small environments with only one or two FortiGate devices, labs, Homelabs, or temporary troubleshooting scenarios, deploying and maintaining an entire management or monitoring infrastructure just to quickly check device status can sometimes introduce more complexity than the requirement itself. The original concept of NOC for FGT also positioned it as a “lightweight FortiGate monitoring assistant,” and made it clear that it is not intended to replace FortiManager or an enterprise-grade NMS.

That is why NOC for FGT was never designed around the idea of becoming a “large platform.”

Why I Keep It Read-Only

When designing NOC for FGT, I have always wanted it to maintain a very clear position: it is first and foremost a monitoring tool, not a configuration tool.

Network device configurations are often directly tied to real production environments. Whether it is a firewall policy, a routing change, or an interface adjustment, a mistake can affect normal network operations. For a tool whose primary purpose is to quickly check device status, adding a large number of configuration capabilities would not only increase complexity, but also introduce additional operational risk.

For that reason, NOC for FGT focuses on viewing status information and assisting with diagnosis. Its goal is to help users understand the current operating condition of a device more quickly, rather than take over complete network configuration and management tasks.

This is not simply a matter of leaving out features. It is a deliberate product boundary. If the purpose of a tool is to help administrators quickly determine whether a device is operating normally, then the first priority should be to make the current state easy to understand, rather than continuously adding management features that are not part of the core use case.

Keeping the tool read-only also allows NOC for FGT to stay focused on the original problem:

Understanding the current state of a FortiGate in a simpler and more direct way.

Why Connect Directly to FortiGate?

Another design decision I made fairly early was to avoid introducing unnecessary intermediate infrastructure.

The topology of NOC for FGT is straightforward:

The app communicates directly with the user’s own FortiGate. It does not require an additional cloud server, database, Agent, or intermediate monitoring node. Device connection information is stored securely on the local device, which was also an important consideration when I chose this architecture. This is how I put the Local-First approach into practice.

If users simply want to view the current status of their own devices, there is no need to introduce an additional backend system just to accomplish that. Fewer components mean lower deployment and maintenance costs, and the overall workflow becomes more direct.

Of course, this design also involves trade-offs. NOC for FGT does not attempt to provide centralized data storage, long-term log analysis, or large-scale cross-organization device management in the way a full monitoring platform would.

But that is exactly the experience I want to preserve: open the tool, then look directly at your own device.

How Are Credentials Stored?

Since NOC for FGT connects directly to FortiGate, how device credentials are stored is something I care about as well.

Currently, device data remains on the local device. It is not synchronized to the cloud and is not uploaded to third-party services. Passwords used to log in to FortiGate are stored in the iOS Keychain using encrypted system storage, rather than being saved directly in the application’s ordinary data storage.

When access to the relevant credentials is required, NOC for FGT also supports Face ID authentication. This preserves the convenience of quickly checking device status from a mobile device without weakening the protection of locally stored credentials.

To me, Local-First means more than simply “no cloud server.” It also reflects a more fundamental principle: device information and login credentials should remain on the user’s own device whenever possible and be protected by the security mechanisms provided by the operating system.

CPU Is at 70%. Now What?

There is another issue that is easy to overlook when building a monitoring tool: displaying data does not necessarily mean helping users understand the state of a device.

For example, suppose CPU utilization is 70%. Looking at that number alone makes it difficult to determine whether a FortiGate is actually experiencing a problem. If the device normally operates at around this level, 70% may be perfectly normal. But if CPU utilization had consistently stayed around 20% and then climbed steadily to 70% over the past hour, that change would be worth investigating.

The same applies to Session counts. 10,000 Sessions may already be very high for some devices, while for other models and workloads it may simply represent normal traffic.

I gradually realized that a more important question than “How much data can the tool display?” is: Can this data actually help administrators understand the current state of the device?

At the moment, NOC for FGT primarily focuses on CPU, Memory, Session, WAN, Interface, and other basic system information. If I continue expanding its capabilities, I would rather focus on trends and diagnostics than simply add more and more numbers to the interface.

A genuinely useful monitoring tool should not merely tell the user, “CPU is currently at 70%.” It should gradually help the user determine whether “70%” is actually something worth paying attention to in the current environment.

NOC for FGT continues to focus on a much more specific problem:

When needed, help me understand the current state of a FortiGate more quickly.

Knowing what not to build is just as important for a lightweight tool as deciding what to build. Only by keeping its scope under control can the product remain simple and direct over the long term.

From “Viewing Status” to “Assisting with Diagnosis”

Looking back, I did not create NOC for FGT because FortiGate lacks management capabilities. Quite the opposite: FortiGate already has a very complete management interface and a mature enterprise ecosystem.

What actually pushed me to start building this tool was another need I repeatedly encountered in day-to-day operations: not every time I open a device am I trying to change its configuration.

Often, all we receive is a simple report such as, “Something seems wrong with the network.” From there, we need to quickly determine whether the device is healthy, whether the WAN is online, whether any interfaces are behaving abnormally, or whether system resources have suddenly changed. This information does not directly solve the problem, but it helps us quickly decide what to investigate next.

If deeper troubleshooting is required, I will still use the FortiGate Web GUI, CLI, logs, or other professional platforms. NOC for FGT is not intended to replace them.

I would rather have it serve as an observation point at the beginning of the troubleshooting process.

When all I want to know is:

“What is happening with this FortiGate right now?”

I should be able to get a basic assessment without first entering a complete and complex management workflow.

To me, that is the problem NOC for FGT was originally created to solve, and it is also why I want to keep it simple.

Try NOC for FGT

If you also want a quicker way to check the current status of your FortiGate, NOC for FGT is available on the App Store.

Download NOC for FGT on the App Store

There Are Already So Many Network Management Tools—Why Is Checking Device Status Still Such a Hassle?

Frank Zhang — Tue, 25 Aug 2026 11:36:51 +0000

Infrastructure Is Moving Beyond Traditional IT Boundaries

For many years, infrastructure management was mainly the responsibility
of professional IT teams. Servers, network devices, virtualization
platforms, security appliances, and business systems were maintained by
administrators with specialized knowledge and experience.

For most users, managing infrastructure meant learning complex concepts,
understanding different vendor tools, and following operational
processes that were often difficult to approach.

However, this is changing.

Today, more people are building and managing their own infrastructure
environments. These environments may include home servers, Docker
services, virtualization platforms, small office networks, self-hosted
applications, and private cloud resources.

Technologies that once existed mainly inside enterprise data centers are
now becoming accessible to a much wider group of users.

But this creates a new challenge:

More people own infrastructure, but not everyone wants to become a
system administrator.

They want visibility and control over their environments. They want to
know whether their services are running correctly and whether something
requires attention. However, they do not necessarily want to spend years
learning complex enterprise operations.

More Tools Do Not Always Mean Better Visibility

Over the past decades, infrastructure monitoring has become
significantly more powerful.

Modern monitoring platforms can collect large amounts of information,
including CPU usage, memory consumption, network traffic, service
availability, logs, and performance metrics.

From a technical perspective, we have more data than ever before.

However, having more data does not always mean having a better
understanding of the environment.

Modern infrastructures are often built from many different components. A
single environment may include virtualization platforms, Docker
workloads, network devices, storage systems, and public-facing services.

Each platform usually provides its own management interface and
monitoring dashboard.

For experienced administrators, these tools are extremely valuable. But
for many users, the real challenge is not collecting information.

The challenge is understanding what the information means.

Most users are not asking:

"What is the exact CPU percentage?"

They are asking:

"Is my environment healthy?"

"Is something changing?"

"Is there anything I should pay attention to?"

"Do I need to take action?"

The future of infrastructure tools should not only focus on displaying
more information.

It should help users build a clearer understanding of their environment.

From Metric Collection to Infrastructure Awareness

Traditional monitoring systems are designed around data collection.

For example, a monitoring system can detect that CPU utilization has
increased from 40% to 80%. This information is accurate.

But users still need to understand:

Is this expected?

Will it affect services?

Does it require action?

This is the difference between collecting metrics and understanding
infrastructure.

A better infrastructure experience should not require every user to
become an expert before they can understand their own environment.

The role of modern tools should be to transform complex technical
information into meaningful operational awareness.

This follows a broader software design principle:

Hide unnecessary complexity and help users focus on outcomes.

Infrastructure management should move in the same direction.

Rethinking the NOC Experience

Traditionally, a NOC (Network Operations Center) represents a
professional enterprise environment.

It usually includes dedicated monitoring platforms, operations teams,
alerting workflows, and structured incident management processes.

This model works extremely well for large organizations.

However, many modern infrastructure environments do not fit this model.

A developer may run multiple Docker services.

A small business may maintain its own servers and network equipment.

A technology enthusiast may operate a private cloud or virtualization
environment.

These environments may not require a full enterprise NOC, but they still
need visibility and operational awareness.

This creates a new opportunity:

How can the core ideas behind NOC capabilities be delivered in a simpler
and more accessible way?

The goal is not to reduce the value of professional infrastructure
management.

The goal is to redesign the experience.

A great tool should not require users to become experts before they can
use it.

Instead, it should help users gradually understand their own
infrastructure.

The Design Philosophy Behind OpsHome NOC

OpsHome NOC was created from this perspective.

It is not designed to replace enterprise monitoring platforms such as
Zabbix, Prometheus, or Grafana. Those platforms solve important problems
around deep monitoring, analytics, and large-scale operations.

Enterprise monitoring platforms are excellent for deep analysis. OpsHome NOC focuses on another layer: helping users quickly understand the operational state of their environment.

OpsHome NOC focuses on a different challenge:

How can users quickly and clearly understand the overall health of their
infrastructure?

The idea is to bring visibility across different types of environments,
including servers, virtualization platforms, Docker services, network
devices, and public services.

For users, the important question is not only the status of individual
components.

The bigger question is:

"How is my infrastructure as a whole?"

By combining different infrastructure perspectives into a simpler
experience, OpsHome NOC aims to reduce complexity and make
infrastructure visibility more approachable.

Behind OpsHome NOC: A Layered Approach to Infrastructure Visibility

To provide a simpler monitoring experience, OpsHome NOC is designed
around a layered architecture that separates user experience, data
processing, and infrastructure communication.

The mobile application acts as the primary interface, allowing users to
view infrastructure status, review important information, and understand
the health of their environment from anywhere.

Behind the application, the cloud API layer provides the connection
between the mobile experience and infrastructure data. It manages
communication, organizes information, and enables a consistent
experience across different infrastructure sources.

For private environments, the local probe approach allows users to
connect their own infrastructure directly. Instead of requiring every
device or service to expose information publicly, the probe works within
the user's environment and collects the required operational
information.

This architecture follows an important principle:

The complexity of infrastructure should remain behind the system, while
the user experience should remain simple.

Users should not need to understand every technical detail behind
virtualization platforms, containers, servers, or network devices just
to know whether their environment is healthy.

The goal is to transform complex infrastructure information into a clear
operational view.

Mobile as a New Infrastructure Management Interface

Mobile devices have already become an important way people manage their
digital lives.

However, infrastructure management still relies heavily on desktop
dashboards and traditional web consoles.

Professional management platforms will always have an important role.

But for daily checks, quick status reviews, and remote visibility,
mobile devices provide a more natural experience.

A mobile NOC is not simply about putting complex dashboards onto a
smaller screen.

It requires a different way of thinking:

What information does a user actually need when they are away from their
desk?

In many cases, users do not need every available metric.

They need:

Current health status
Important changes
Potential issues
Areas that require attention

This is where mobile infrastructure management can provide additional
value.

Making Infrastructure More Accessible

In the future, infrastructure will continue becoming more distributed.

Cloud services, virtualization, containers, self-hosted applications,
and edge environments will allow more people to operate their own
technology systems.

Infrastructure management should not remain limited to a small group of
specialists.

Just as smartphones made photography accessible without requiring
everyone to become a professional photographer, modern infrastructure
tools should make powerful capabilities easier to approach.

The goal is not to remove expertise.

The goal is to make expertise more accessible.

This is the direction OpsHome NOC continues to explore:

Making infrastructure management simpler, more intuitive, and available
to more users.

Helping people not only own their infrastructure, but also understand
and control it.

Learn more:

https://opshome.run

Technical articles:

https://docs.opshome.run

Private Network Monitoring: Why Inside-Out Monitoring Is Becoming More Important

Frank Zhang — Wed, 19 Aug 2026 05:20:58 +0000

External monitoring was the only practical option for a long time. Now it is not. And the difference matters more than most people realize.

The Old Way Had a Hidden Cost

The traditional approach to uptime monitoring goes like this: sign up for a cloud monitoring service, enter the public URL of your service, and wait for alerts when something breaks. Simple. Familiar. And for public websites, it still makes complete sense.

But somewhere along the way, this model got stretched into territory it was never designed for. People started using external monitors for NAS devices, internal dashboards, home servers, self-hosted apps, private APIs — services that were never meant to be reachable from the outside. And to make the monitoring work, they started opening ports. Adding reverse proxies. Punching holes in firewalls. Exposing management interfaces to the public internet just so a third-party service could check if they were online.

That is a significant tradeoff to accept, and most people accept it quietly because they don't see an alternative.

What You Give Up When You Monitor From Outside

External monitoring works by simulating what a user on the public internet would see — an HTTP GET from a remote probe server, a TCP SYN to a port, an ICMP echo request. That is genuinely useful signal for public infrastructure. But it comes with several costs that are easy to overlook.

You expose your attack surface

To be checked from outside, a service has to be reachable from outside. That means open ports, public DNS A records, or a reverse proxy forwarding traffic inward through NAT. Every one of those is an entry point. You are expanding your attack surface not because your service needs to be public, but because your monitoring tool needs to reach it.

Attackers routinely run Shodan scans and port sweeps looking for exposed management interfaces — Synology DSM on :5001, Proxmox VE on :8006, Portainer on :9000, Grafana on :3000. If your monitoring requires these to be reachable from the public internet, you have already answered a question that is better left unanswered.

You hand metadata to a third party

External monitoring services learn quite a bit about your infrastructure just by doing their job. Your public IP addresses. The HTTP fingerprint of your services. Response times and TTL patterns. TLS certificate details and renewal windows. When your systems restart. What software versions you run.

For a public website this is fine — that information is already public. For a private NAS, a self-hosted Vaultwarden instance, or a home Proxmox cluster, it is a different situation. Your infrastructure topology is not something that needs to live on a vendor's servers indefinitely.

External monitoring depends on inbound reachability. Private monitoring does not.

To be clear upfront: OpsHome NOC is a SaaS product. The Docker Probe connects outbound to OpsHome Cloud over HTTPS — and if your ISP goes completely dark, the probe loses its reporting path too. We are not going to pretend otherwise.

But that is not the failure mode that causes the most noise in practice. The real problem is inbound reachability failures — situations where your internal services are perfectly healthy, but the external probe cannot reach them because of something on the network boundary.

Consider: CGNAT carriers assign private WAN addresses to residential customers, making inbound connections structurally impossible regardless of port forwarding rules. Dynamic IP assignments change without warning. Some ISPs apply DPI filtering to inbound traffic on non-standard ports. BGP route instability between a monitoring provider's datacenter and your upstream can make your edge appear unreachable while your local network runs cleanly.

In every one of these cases, an external monitor reports your service as down. The probe does not, because it never depended on inbound reachability in the first place — it connects outbound to a stable cloud endpoint over TCP 443, which is the most consistently available path in almost any network environment.

The distinction matters: private monitoring reduces false positives from inbound path failures. It is not immune to a complete ISP outage. If you lose your internet connection entirely, you lose monitoring visibility either way — and understanding that difference is part of operating a monitoring system honestly.

What Changes When You Monitor From Inside

Private monitoring inverts the model. Instead of reaching into your network from outside, a small agent runs inside your network and reaches out. The direction reverses. The implications are significant.

Nothing needs to be exposed

A private monitoring agent connects outbound to the cloud over HTTPS — the same direction as any browser, any software update, any API call your apps already make. There are no inbound ports to open. No firewall rules to add. No reverse proxy to configure. Your router's NAT stays closed.

Your NAS panel, your Proxmox interface, your internal services — they stay exactly as unreachable as before. The monitor checks them by name or private IP from inside the network, the same way you would from your laptop.

Local failures become visible, not invisible

When you monitor a service from inside the same network, you see what the service is actually doing — not what it looks like through one particular internet path. A container that crashed but left its port bound would fool an external TCP check. A service returning HTTP 502 from a broken upstream would look perfectly reachable from outside. A Synology DSM volume in degraded state has no public-facing signal at all.

Private monitoring checks what is real. External monitoring checks what is visible from one vantage point on the public internet. These are not the same thing, and the gap between them is where silent failures live.

Fewer false alarms from network boundary noise

External monitoring generates false alarms when the network path between the probe server and your edge is disrupted — not because your services failed, but because the monitoring infrastructure could not reach them. For home and homelab users this happens more often than people expect: carrier CGNAT, dynamic DNS propagation lag, residential ISP routing quirks, and brief WAN address changes all trigger it.

The probe does not depend on that path. It reports outbound over TCP 443 to a stable cloud endpoint. The signal you get is cleaner — closer to "did the service actually fail" rather than "was the service reachable from a third-party datacenter in another country at that particular moment."

To be direct: a genuine total internet outage affects both. The probe cannot report without connectivity. The honest framing is that private monitoring reduces the noise floor of your alerting, not that it eliminates the dependency on connectivity altogether.

What Private Monitoring Can See That External Monitoring Cannot

This is where the technical gap becomes concrete. External monitoring checks a network endpoint — a port, a URL, a DNS response. It cannot see anything beyond the response it receives. Private monitoring runs from inside the same environment as your infrastructure, which means it has access to context that simply does not exist on the public internet.

Synology DSM — beyond port reachability

A Synology NAS running DSM 7 exposes a management interface on port 5001. An external monitor can tell you whether that port is responding. It cannot tell you:

Whether a RAID volume is degraded or rebuilding
Whether disk temperatures are approaching the thermal threshold
Whether the system is under memory pressure from running containers
Whether a Docker container on the NAS is in a crash loop
What the real-time disk I/O utilization looks like across physical drives
How long the system has been running since the last restart

A private monitoring agent running on the NAS itself — or inside the same network — can collect all of this. The difference between "the DSM page loaded" and "the NAS is healthy" is significant, and external monitoring cannot bridge it.

OpsHome NOC — CPU, memory, temperature, uptime, and container count, all collected from inside the private network. None of this is visible to an external monitor.

Proxmox VE — cluster state is not a public endpoint

Proxmox exposes its management API on port 8006. External monitoring can confirm the API is responding. It cannot tell you:

Whether a VM or LXC container is running, stopped, or paused
Whether a storage backend — ZFS pool, LVM, NFS, Ceph — is healthy or degraded
Whether a node in the cluster has lost quorum
Whether CPU steal time is elevated on a hypervisor host
What the per-VM memory balloon pressure looks like

Infrastructure state is not a public URL. It lives inside the management plane, and the management plane is not something you want exposed to the internet just so a monitoring tool can read it.

Docker containers — names, not just ports

Every external monitor requires a hostname or IP address and a port. Docker containers often do not have stable, predictable ports from the outside. They may bind to 127.0.0.1 only, use internal bridge networks, or sit behind a reverse proxy that routes by Host header.

A private monitoring agent running inside the Docker network can reach containers by name — http://nextcloud:80, http://vaultwarden:3000 — without any of those services being reachable from outside. No port mapping required. No reverse proxy required for the health check. The container either responds from inside its network or it does not.

The Infrastructure That Actually Exists Today

The growth of homelab culture, self-hosted software, NAS ecosystems, and personal cloud infrastructure has quietly changed what "my services" means for a large number of people. Five years ago, most personal infrastructure was entirely cloud-hosted and entirely public. Today, a significant portion is private by design: private IPs, private networks, services that are meant to be reached only from inside the home or office.

Most uptime monitoring tools were built for the world where all services have public domain names and external reach is guaranteed. That model works for what it was designed for. It does not map well to a Synology NAS running Jellyfin, a Proxmox cluster hosting a handful of LXC containers, or a Raspberry Pi running Pi-hole and Home Assistant behind a residential ISP.

Private monitoring is not a niche feature. It is an adaptation to how infrastructure actually looks for a growing segment of users — one that the tooling has been slow to catch up to.

Your Devices. Your Network. Your Rules.

The ability to know whether your services are healthy should not require you to expose management interfaces to the public internet. It should not require you to open inbound ports on a residential connection. It should not require your NAS administration panel to be reachable from a monitoring provider's datacenter.

Private monitoring is what it looks like when the monitoring model fits the infrastructure — not the other way around. The agent runs inside your network. It checks what is actually there. Results go out over a standard outbound connection. Access does not come in.

You built the infrastructure. You should be the one who can see it clearly.

Where This Is Going

More services are running privately. More users are running their own hardware. The combination of NAS platforms, container runtimes, and virtualization tools that were once datacenter-only is now sitting in spare bedrooms and home offices around the world. The monitoring model needs to follow the infrastructure, not the other way around.

Private-first monitoring will become the standard for anyone running serious personal infrastructure — not because external monitoring is going away, but because the combination of internal health visibility and external reachability checking is obviously more complete than either one alone. External monitoring tells you what the world can see. Private monitoring tells you what is actually happening. Both answers matter.

The question is not whether private monitoring belongs in a serious setup. The question is how long it takes for the tooling to catch up with the infrastructure it needs to serve.

OpsHome NOC was built around this model. The Docker Probe is a lightweight Go binary running inside a hardened container on your network. It connects outbound over HTTPS/TLS — no open ports, no inbound firewall rules, no third-party access to your services. Cloud monitoring handles your public endpoints via HTTP, TCP, SSL, DNS, and ICMP. Private monitoring handles everything behind your NAT. You see both from the same app.

Read the Install Docker Probe for private homelab monitoring →

OpsHome NOC

Private monitoring for NAS, Docker, Homelab, and personal infrastructure.

Your devices. Your network. Your rules.

Originally published on OpsHome Docs.