DEV Community: Jafar Tavana

VMware Beacon Probing: Network Failover Detection Mechanism

Jafar Tavana — Mon, 15 Jun 2026 07:44:49 +0000

Abstract

Virtualized environments require highly resilient network architectures to ensure the uninterrupted availability of critical workloads. While local link state monitoring provides foundational fault detection, it is frequently blind to upstream network failures that occur beyond the immediate physical connection of the host. This paper explores VMware vSphere's Beacon Probing, a software-based, switch-agnostic network failover mechanism designed to address these upstream blind spots. By continuously transmitting and evaluating specialized Layer 2 Ethernet broadcast frames across a team of network interface cards, beacon probing effectively maps the logical health of the upstream broadcast domain. Through a comprehensive analysis of its operational mechanics, specific packet characteristics, topology requirements, and inherent limitations, this paper elucidates how beacon probing operates and delineates the optimal scenarios for its deployment in modern data centers.

Introduction

Modern virtualized data centers rely fundamentally on continuous network connectivity to maintain application uptime and facilitate infrastructure management. To achieve high availability, administrators group multiple physical Network Interface Cards (NICs) into logical teams, providing redundancy in the event of hardware or cable failures. Traditionally, the primary method for triggering a failover within these NIC teams has been link state tracking, which monitors the electrical carrier signal on the physical interface. While highly efficient for local outages, this fundamental approach lacks visibility into the broader network fabric extending beyond the initial switch hop.

The primary problem addressed by advanced failover mechanisms is the detection of logical or upstream path failures that do not result in a loss of local link state. For example, if an upstream switch fails, or if an inter-switch link goes offline, the local NIC connected to the first-hop switch will still report an active link status, resulting in a network black hole where traffic is sent but never successfully routed. The scope of this paper focuses specifically on software-based probing techniques utilized by the hypervisor to continuously validate the end-to-end integrity of the Layer 2 broadcast domain without relying on hardware-specific network configurations.

Existing approaches to this problem are often insufficient for several critical reasons. First, simple link state tracking is structurally incapable of detecting upstream misconfigurations or switch-to-switch connection severances, leaving virtual machines silently disconnected from the broader network. Second, while some physical switches offer proprietary features like Link State Tracking to propagate upstream failures downward, these solutions are heavily vendor-dependent, add significant complexity to network configurations, and are frequently unsupported in heterogeneous or highly complex upstream topologies.

To address the shortcomings of traditional link state dependencies, this paper provides a thorough examination of VMware vSphere's beacon probing failover mechanism. The core contributions of this paper are twofold. First, it provides a comprehensive architectural breakdown of the beacon probing packet structure, specifically analyzing its reliance on Layer 2 Ethernet broadcast mechanics over traditional IP-based routing. Second, it formulates precise topology guidelines and failure detection logic frameworks, demonstrating precisely why a minimum of three active uplinks is mathematically necessary to isolate upstream failures without falling victim to split-brain routing ambiguities.

Related Work

Local Physical Link State Detection

The most ubiquitous method for network fault detection relies on continuous monitoring of the physical layer carrier signal. The core idea behind this approach is that a severed cable or an unpowered first-hop switch port will immediately cause the local network interface to transition to a down state. The primary strength of physical link monitoring is its instantaneous reaction time and zero computational overhead, as the detection is handled entirely at the hardware level. However, its fatal weakness is its complete blindness to any network anomalies occurring beyond the direct local connection. Compared to beacon probing, which actively maps the logical broadcast domain, link state detection serves only as a baseline physical indicator rather than a comprehensive health monitor.

Switch-Assisted Hardware Failure Propagation

To overcome the limitations of strictly local link detection, network vendors developed hardware-assisted protocols such as Link State Tracking and Trunk Failover. The core concept here is that an upstream switch monitors its own core connections; if an upstream link fails, the switch intentionally disables its downstream ports, forcing the connected servers to recognize a link-down event and initiate local failover. While this provides a deterministic and fast failover mechanism, it severely restricts network design by mandating vendor-specific hardware capabilities and strict hierarchical topologies. Beacon probing presents a stark contrast to this hardware-centric approach, offering a purely software-based, switch-agnostic alternative that operates transparently across multi-vendor fabrics.

Application-Layer and Layer 3 Polling Mechanisms

In complex enterprise networks, routing protocols and technologies like Bidirectional Forwarding Detection (BFD) or ICMP polling are often used to monitor end-to-end path viability. The fundamental idea is to continuously exchange IP packets between specific endpoints at Layer 3 or Layer 4 to verify that the entire routing path remains traversable. While these methods excel at verifying end-to-end connectivity across routed networks, they require complex IP address configurations, subnet planning, and significantly higher computational overhead. Beacon probing differs significantly from these methods by operating entirely at Layer 2; it relies exclusively on MAC-level broadcast frames without any IP configuration requirements on the VMkernel ports or port groups.

Method/Approach

Architectural Topology Framework

The deployment of beacon probing necessitates a specific physical network architecture to function deterministically. The hypervisor host must be provisioned with a NIC team consisting of at least three physical uplinks (e.g., two active and one standby, or three active) connected to diverse upstream switches. If only two uplinks are utilized, a failure in the communication path results in a "split-brain" scenario where neither NIC receives the other's beacons, making it impossible for the host to identify whether the sender, the receiver, or the path has failed. By mandating a three-uplink topology, the system leverages quorum logic: if a single upstream path fails, the remaining two NICs will still successfully exchange beacons, allowing the hypervisor to isolate and penalize the specific isolated uplink.

Transmission Mechanics and Packet Design

The beacon probing mechanism relies on highly specialized, lightweight Ethernet frames designed to traverse an entire Layer 2 broadcast domain. Instead of relying on specific IP addresses, the mechanism utilizes standard Ethernet broadcast frames addressed to the destination MAC address of FF:FF:FF:FF:FF:FF. The packet structure is deliberately minimal, consisting of an 18-byte Ethernet header and approximately 71 bytes of payload, resulting in a total frame size of merely 89 bytes. Furthermore, these frames are tagged with a specific Ethernet protocol type (0x8922) that clearly identifies them as beacon probe packets, allowing them to be forwarded by physical switches to all ports within the broadcast domain without necessitating complex routing decisions.

Failure Detection Pipeline

The operational logic of beacon probing operates through a continuous, cyclical pipeline executed by the hypervisor. The process can be abstracted into the following structured steps:

Periodic Transmission: Every active physical NIC within the configured team independently generates and transmits a beacon broadcast frame at an interval of approximately one second.

Listener Evaluation: Every other active NIC in the team continuously listens for incoming broadcast frames matching the 0x8922 EtherType from its peers.

Threshold Monitoring: The hypervisor maintains a counter for expected packets; if an individual uplink fails to receive three consecutive beacon frames from a specific peer, a failure flag is triggered.

Traffic Rerouting: Once the three-miss threshold is breached, the hypervisor correlates the missed packets against the total array of NICs, identifies the isolated uplink, marks its path as degraded, and seamlessly fails over VM traffic to the remaining healthy interfaces.

Proposed Evaluation Methodology

To validate the efficacy of beacon probing against traditional link state mechanisms, a structured, hypothetical testing environment should be employed. The testbed would consist of an ESXi host configured with three uplinks connected to a tiered array of physical switches, handling continuous UDP streaming traffic. The evaluation plan would introduce two distinct failure scenarios: a physical cable disconnection at the host level, and an upstream inter-switch link failure that leaves the host's direct link state intact. Performance metrics would include total failover latency (measured in milliseconds from the time of cable severing to the resumption of UDP traffic) and network overhead generated by the broadcast packets, ultimately proving that beacon probing captures the upstream failures that local tracking entirely misses.

Discussion

Practical Implications

The implementation of beacon probing provides substantial operational resilience for data centers utilizing stacked switches or heavily meshed upstream topologies. In environments where hardware-based link state propagation cannot be reliably deployed, administrators can leverage this software-defined approach to guarantee high availability for mission-critical virtualized workloads. Furthermore, because the mechanism operates purely at Layer 2 without any dependency on VMkernel IP configuration, it can be deployed seamlessly across existing VLANs and port groups with minimal architectural redesign.

Limitations and Failure Modes

Despite its utility, beacon probing is not universally applicable and suffers from several notable limitations. First, it is fundamentally incompatible with IP Hash load balancing algorithms; IP Hash requires strict deterministic routing behavior from the upstream switch, which conflicts directly with the reactive traffic shifting performed by beacon probing. Second, because it relies on Layer 2 broadcast packets, scaling this mechanism across a massively flat, unsegmented network can contribute to broadcast storms and unnecessary processing overhead on edge devices. Third, the system is highly vulnerable to ambiguous failure states if implemented incorrectly with only two uplinks, as the resulting split-brain logic can trigger unnecessary route flapping and severe packet drops.

Ethical Considerations and Risks

From a security and operational risk standpoint, broadcast-based detection mechanisms introduce specific vulnerabilities that must be actively managed. The primary security risk involves localized Denial of Service (DoS); a malicious actor who gains access to the Layer 2 domain could theoretically inject spoofed Ethernet frames containing the 0x8922 EtherType. By flooding or intentionally withholding these spoofed packets, an attacker could artificially manipulate the hypervisor's failover logic, forcing traffic onto compromised or sub-optimal physical links. Additionally, there is a risk of severe network instability if administrators misunderstand the required thresholds; misconfiguring the expected beacon intervals or deploying the feature on incompatible switch topologies can lead to continuous, systemic outages that are highly difficult to troubleshoot.

Future Directions

Looking forward, the architecture of beacon probing could be significantly enhanced to operate reliably within zero-trust network environments. One vital area for future work is the development of cryptographic validation for the beacon payloads; implementing lightweight cryptographic signatures within the 71-byte payload would prevent malicious injection and ensure that hosts only react to verified internal broadcasts. Furthermore, integrating machine learning algorithms could allow the hypervisor to dynamically adjust the one-second polling interval; during periods of extreme network congestion, the system could automatically expand the timeout threshold, preventing false-positive failovers triggered strictly by transient network latency rather than true hardware failure.

Conclusion

Network availability in virtualized data centers demands fault detection mechanisms that extend beyond the physical boundaries of the host server. VMware’s beacon probing achieves this by utilizing lightweight, standard Ethernet Layer 2 broadcasts to continuously map the logical viability of the upstream broadcast domain. By establishing a rigorous three-miss threshold and mandating a minimum of three physical uplinks, the protocol provides a highly reliable, switch-agnostic methodology for circumventing upstream network black holes that traditional link state tracking cannot detect.

While not suitable for all environments—particularly those utilizing IP Hash load balancing or massively flat Layer 2 networks—beacon probing remains a powerful tool within the systems administrator's arsenal. By bridging the critical gap between localized physical fault detection and heavy, IP-dependent routing protocols, it ensures that workloads remain resilient across increasingly complex and unpredictable upstream network topologies. As virtualized infrastructure continues to evolve, software-defined resilience mechanisms like beacon probing will remain essential to maintaining continuous application delivery.

Why Local System Monitoring Still Beats the Cloud — and How I Built My Own Dashboard to Prove It

Jafar Tavana — Sat, 13 Jun 2026 15:44:24 +0000

Over the past few years, the technology industry has moved almost everything to the cloud. Infrastructure, storage, communication, analytics — the default answer to nearly every engineering problem now begins with "there's a SaaS for that." And in many cases, that is the right answer.

But there is one domain where I believe the cloud-first instinct leads us astray: system monitoring on your own machine.

This article explains why, and how I responded by building an open-source, fully local Windows 11 monitoring dashboard using Next.js, React, TypeScript, Chart.js, and Python — with zero cloud dependencies.

The Hidden Cost of Cloud-Based Monitoring

When most developers think about monitoring, they reach for familiar names: Datadog, New Relic, Grafana Cloud, or one of dozens of similar platforms. These are powerful tools, built for distributed systems at scale. For monitoring a fleet of production servers, they make complete sense.

But when the subject is a single developer workstation or personal machine, the equation changes — and not in the cloud's favor.

Privacy is the first concern. Every cloud monitoring agent ships your hardware data — CPU load, memory usage, running processes, network traffic — to a third-party server. You are trusting an external company with a continuous, real-time stream of information about exactly what your machine is doing and when. For developers working with proprietary code, sensitive credentials in environment variables, or client data, that is a risk that rarely gets the scrutiny it deserves.

Latency is the second. A cloud dashboard receives your data, ingests it into a pipeline, stores it, and then delivers it back to your browser — often with a delay of five to thirty seconds. For a developer who wants to watch CPU frequency respond to a compile job, or track memory pressure during a Docker build, thirty seconds of lag is not monitoring. It is history.

Cost is the third. Free tiers on most monitoring SaaS platforms are intentionally limited. High-resolution metrics, long retention windows, and multiple machines quickly push you into paid tiers that are priced for enterprise budgets, not individual engineers.

And beneath all three of these is a philosophical point: you should not need to ask permission from the internet to see what your own hardware is doing.

What a Local-First Architecture Looks Like

When I set out to build a better alternative, I had a clear set of requirements:

All data stays on the local machine, always
Updates must be genuinely real-time — sub-second refresh
The UI should match or exceed what commercial tools offer visually
The entire stack should be built on technology most developers already know
Setup should be achievable in under five minutes

The architecture I landed on has three layers.

The collection layer is a Python script using psutil, the battle-tested cross-platform library for system information. It runs as a background process, gathering CPU usage per core, memory breakdown, disk throughput, network interface statistics, GPU metrics via nvidia-smi, and the top processes by resource consumption. Every second, it writes atomic JSON snapshots to a local monitor/data/ directory.

The API layer is a set of Next.js Route Handlers — one per category — that read those JSON files and serve them over localhost. There is no network boundary, no authentication handshake, no rate limit. A request from the browser to /api/cpu returns fresh data in under a millisecond.

The UI layer is a React application with Chart.js rendering rolling 60-second line charts for every live metric. KPI cards show current values with color-coded thresholds. Tailwind CSS provides the dark, terminal-inspired visual design. Everything polls at one-second intervals, giving the dashboard the feel of a native application rather than a web page.

The result: a monitoring tool that is faster, more private, and more informative than anything I have used on a cloud platform — and one I fully understand and control, because I built every line of it.

The Developer Experience Matters Too

One practical decision I made early was to make the project self-generating. Rather than asking someone to clone a repository and configure a dozen files by hand, the entire scaffold is produced by a single Python script — create_project.py. Running it creates the full folder structure, writes every source file, and executes npm install automatically. The only commands a developer needs to run after that are:

npm run dev
python monitor/writer.py

And within seconds they have a live dashboard at http://localhost:3000.

This matters because the best monitoring tool is the one people actually use. Friction at setup is where most side projects die. Eliminating that friction was as important to me as the technical architecture itself.

What This Taught Me About Tool Design

Building this project reinforced several convictions I hold about software engineering.

The first is that complexity should be proportional to the problem. A cloud monitoring platform for a single laptop is an engineering mismatch. It introduces distributed systems complexity — agents, pipelines, ingestion queues, API authentication — into a problem that is fundamentally local. A file on disk and a Route Handler is sufficient, and sufficient is better.

The second is that open source is still the most effective way to share knowledge. Publishing this project forces a level of documentation discipline — README, architecture diagrams, extension guides — that makes the ideas inside it accessible to other engineers who may face the same problem. Several developers have already asked about extending it to AMD GPUs and battery monitoring on laptops. That kind of conversation does not happen with a closed tool.

The third is that privacy deserves to be a first-class engineering requirement, not an afterthought. When I chose to build local-first, I did not do it despite the constraints it imposed — I did it because of them. Those constraints produced a faster, simpler, more trustworthy system.

Try It Yourself

The project is open source and available on GitHub:

🔗 https://github.com/jafartavana01/windows-monitor-dashboard

It covers CPU, memory, storage, network, GPU, processes, and OS information — all updated live, all on your machine, all yours.

If you are a developer who spends significant time on Windows and has ever felt that existing monitoring tools were either too heavy, too expensive, or simply too nosy about your hardware, I hope this project offers a better path.

I would welcome feedback, contributions, and ideas for new monitoring categories. The architecture is intentionally simple to extend — and the best features of any open-source tool are always the ones the community brings to it.

Jafar Tavana — Software Developer
GitHub: https://github.com/jafartavana01

Meet Vault: A Beautiful, Zero-Dependency Password Manager Built in a Single Python File By Jafar Tavana · powerinfossl@gmail.com

Jafar Tavana — Fri, 12 Jun 2026 15:19:53 +0000

We live in a world where the average person manages dozens — sometimes hundreds — of passwords. Yet most solutions to this problem fall into two uncomfortable camps: cloud-based services that require you to trust a third party with your most sensitive data, or bloated desktop applications that demand complex installations and constant updates.

What if there was a third option? What if you could run a fully-featured, beautifully designed, encrypted password manager with nothing but Python — no pip, no npm, no frameworks, no internet connection required?

That's exactly what Vault is.

What Is Vault?

Vault is a web-based password wallet that lives entirely inside a single Python file. You run it, a local server starts on your machine, your browser opens, and you're greeted with a sleek dark-mode interface that looks like it belongs in a modern SaaS product — not a hobby script.

Every password you store is encrypted before it ever touches disk. Lock it when you're done. Close the tab. Walk away. Your data stays safe.

The project is open-source and available on GitHub:
👉 github.com/jafartavana01/password-wallet

The Philosophy: One File, No Compromise

Most developers, when building a web app, reach for Flask, React, SQLite, and a handful of crypto libraries before writing a single line of business logic. Vault was built under a different constraint: Python's standard library only.

This constraint was deliberate, and it shapes everything about the project:

No installation step. You don't need a virtual environment. You don't need pip. If you have Python 3.7 or higher, you already have everything Vault needs.
No supply chain risk. Every line of code that runs on your machine was written by the project author — not pulled from a registry of third-party packages. That matters a great deal for a security-sensitive tool.
Fully portable. Drop the file on a USB drive, carry it to any machine, run it. No setup, no configuration wizard.

bashpython password_wallet.py

That's the entire installation process.

The Security Model

A password manager that isn't secure isn't a password manager — it's a liability. Vault takes a layered approach to protecting your data, implemented entirely from Python's built-in hashlib and hmac modules.

Master Password Verification

When you set your master password for the first time, Vault never stores it. Instead, it derives and stores a PBKDF2-HMAC-SHA256 verifier — a one-way hash computed over 200,000 iterations with a fixed salt. The original password cannot be recovered from this verifier.

Per-Entry Encryption

Each entry you save is individually encrypted before being written to wallet.json. The process works like this:

A fresh 16-byte random salt and 16-byte IV are generated for the entry using Python's secrets module (cryptographically secure random generation).
Your master password is combined with the salt and stretched through PBKDF2 into a 32-byte key.
That key is split into an encryption key and a MAC key using SHA-256 domain separation.
The entry data is encrypted with an XOR stream cipher driven by a SHA-256 block chain.
A HMAC-SHA256 tag is computed over the salt, IV, and ciphertext and appended to the blob.

When you unlock the vault and load your entries, the HMAC is verified before any decryption takes place. If the tag doesn't match — wrong password, corrupted file, or tampered data — decryption is rejected entirely.

In-Memory Only

Decrypted entries never touch disk. They live only in your browser's JavaScript memory for the duration of your session. The moment you click Lock, the master password is cleared from memory, all entries are wiped, and the app returns to the lock screen. Nothing sensitive remains.

The Interface

The UI was designed to feel like a real product. Dark navy backgrounds (#0D1117), electric blue accents (#58A6FF), and a terminal-inspired monospace font for passwords — the aesthetic signals that this is a security tool, not a toy.

The Lock Screen

A full-screen lock screen greets you on every launch. The password input has a subtle circuit-trace animation on focus — the border glows and traces around the field like an unlocking circuit. It's a small detail, but it sets the tone.

The Vault

Once unlocked, the interface splits into a familiar two-panel layout: a sidebar listing all your entries, and a main panel showing the selected entry's details. Entries are color-coded by their auto-generated avatar (based on the entry title), and tagged by category — Web, Finance, Email, Social, Work, or Other.

Password Detail View

Each entry displays its password behind a mask by default. A toggle reveals it. A one-click copy button grabs the username, password, or URL to your clipboard with a toast notification confirming the action. A color-coded strength bar tells you at a glance how robust a given password is.

The Generator

Built into the Add/Edit modal is a fully configurable password generator. Choose your length (8 to 64 characters), toggle uppercase, lowercase, digits, and symbols, hit Generate, and a cryptographically random password appears. One more click applies it directly to the password field.

The Data File

All your entries are stored in a single file: wallet.json. It looks something like this:

json{
"verifier": "a3f8b2c1d4e5...",
"entries": [
{
"id": "3e9a1c4f",
"data": "dGhpcyBpcyBhIGJhc2U2NCBlbmNyeXB0ZWQgYmxvYg==",
"updated": "2025-06-12"
}
]
}

The data field is an opaque base64 blob. Without the master password, it reveals nothing about the entry's title, username, password, URL, or notes. The file is safe to back up, sync to a personal cloud, or transfer between machines.

Searching and Organizing

The search bar in the header filters entries in real time across titles, usernames, URLs, and categories. A stats bar beneath the header shows the total entry count, number of active categories, and — usefully — a count of weak passwords so you know when it's time to do some housekeeping.

Who Is This For?

Vault is built for a few specific types of people:

Developers and sysadmins who want a local, auditable password manager they can read top-to-bottom in a single sitting. There are no black boxes here.

Privacy-conscious users who are uncomfortable with cloud-based password managers and want their data to stay on their own hardware.

Anyone who needs a portable solution — running on a locked-down corporate machine, an air-gapped workstation, or a Raspberry Pi. If it runs Python, it runs Vault.

Getting Started

bash# Clone the repository
git clone https://github.com/jafartavana01/password-wallet.git
cd password-wallet

Run

python password_wallet.py

Your browser will open automatically. On first launch, you'll be asked to set a master password — choose something strong, and write it down somewhere safe. There is no password recovery mechanism by design.

The wallet.json file is created automatically in the same directory. Back it up regularly.

What's Next

This project demonstrates what's possible when you treat constraints as a creative challenge rather than a limitation. Future directions could include:

Import/export from common formats (CSV, 1Password, Bitwarden)
Browser extension for auto-fill
Optional AES-256-GCM encryption via the cryptography package for users who want audited crypto primitives
TOTP / two-factor authentication code support

Contributions and ideas are welcome via GitHub Issues and Pull Requests.

Final Thoughts

There's something satisfying about a tool that does exactly one thing, does it well, and asks nothing of you except Python. Vault isn't trying to be Bitwarden or 1Password. It's trying to be the thing you can hand to anyone, tell them to run python password_wallet.py, and have them storing passwords securely in under 60 seconds.

Sometimes that's exactly what you need.

GitHub: github.com/jafartavana01/password-wallet
Author: Jafar Tavana — powerinfossl@gmail.com