VGMC — The Virtual Grandmaster Clock Pattern

The problem VGMC solves

Every traditional PTP deployment eventually hits the same operational problem: if the grandmaster fails, every downstream client either has to fail over independently (noisy, slow, frequently broken in edge cases) or the operator has to reconfigure them all to point at a new grandmaster IP. The first option relies on BMCA and secondary-grandmaster priorities, which work but introduce a transition event. The second option is manual work at potentially hundreds or thousands of clients, during which the fabric is in an inconsistent state.

VGMC sidesteps both options by presenting a stable IP endpoint to clients that is detached from any specific backing grandmaster. Clients point at the VGMC IP once, at initial deployment, and never need to change. The VGMC is served by whichever backing Agent the Mesh currently selects, and the selection changes transparently as Agents come and go.

The analogy to draw is a load-balanced service endpoint in a standard application architecture. An HTTP service behind an ELB has a stable DNS name; the ELB routes requests to whichever backend instance is healthy; instance failures are invisible to clients. VGMC is the same pattern applied to PTP — a stable endpoint with a dynamic backing pool.

Components — what's in a VGMC

A VGMC deployment combines three things.

• ●Backing Agents — two or more Timebeat Agents, each with its own time input (GNSS, upstream PTP, or other supported input). Typically 3 for a minimal redundant deployment; more for capacity scaling.
• ●PTP² Mesh coordination — running on every backing Agent, coordinating which one is currently serving which downstream clients and handling failover when backing Agents degrade.
• ●A client-facing virtual endpoint — typically an anycast IP, a load-balanced DNS name, or a Linux VRRP / keepalived address that routes to whichever backing Agent is currently active. Downstream PTP clients point at this endpoint and never need to know about the backing pool.

Deployment topologies

Three common topologies cover most VGMC deployments.

How the Mesh routes downstream clients to a specific backing Agent

The subtle part of VGMC is how the Mesh decides which backing Agent currently serves a given downstream client. The answer depends on the endpoint type.

For an anycast IP, the underlying network routes the client's packets to the topologically nearest Agent advertising the anycast address. BGP and IP routing handle the selection; the Mesh contributes by telling each Agent whether to advertise the anycast route (advertise if healthy and has capacity; withdraw if degraded or over capacity). Failover happens at the IP routing layer, typically within one BGP convergence cycle.

For a VRRP / keepalived address, one Agent is the 'primary' at any given time (holding the virtual MAC) and the others are secondaries. When the primary degrades, VRRP elects a new primary and the virtual MAC moves. Failover is in the hundreds-of-milliseconds range. Simple on a flat LAN, harder to stretch across L3 boundaries.

For a DNS-based endpoint (less common for PTP but used in some managed service deployments), clients resolve the DNS name and connect to the returned IP. DNS-level load balancing or health checking handles the Agent selection, with shorter TTLs for faster failover. The tradeoff is DNS caching at clients, which can delay failover unless TTLs are aggressive.

What downstream clients see — and what they don't

From a downstream PTP client's perspective, a VGMC looks like a single grandmaster at a single IP. The client runs standard PTP discovery against that IP and synchronises to whatever clock the VGMC returns. The client has no concept of the backing Agent pool; it sees the PTP messages as coming from one grandmaster with one set of clock quality fields.

When a backing Agent degrades and the Mesh rebalances, the downstream client's connection may migrate to a different backing Agent. Ideally this is invisible — the client sees a continuous stream of PTP messages with consistent clock quality fields, because both the degrading Agent and the replacement were serving time disciplined by their own Clock Ensembles. There is no step change in the client's offset estimate because the replacement Agent's clock state is very close to the degrading Agent's state at the moment of transition.

In pathological cases — the degradation is sudden and the Ensembles were not well-aligned at the moment of transition — the client may see a small offset discontinuity. For most downstream applications this is well below the operational tolerance (microseconds vs. the application's tens of microseconds budget); for tight applications (finance HFT cards), the Mesh's hysteresis parameters and the backing Agents' Ensemble tuning are set to keep transitions as smooth as possible.

Capacity planning — how many backing Agents do you need

The answer depends on the load pattern and the redundancy target. For minimal redundancy (N+1 — survive any single-Agent failure), two backing Agents is enough. For production redundancy (survive any single failure without load exceeding 100% on the remaining Agents), the arithmetic is: sum of downstream clients ÷ (number of Agents − 1) ≤ seats_to_offer per Agent.

For a typical Shelf deployment serving 100 downstream clients with 3 backing Agents, each Agent should advertise seats_to_offer ≥ 50 (survive loss of one Agent, remaining two carry 50 each). Each Agent has plenty of headroom to serve more if needed, but the 50-per-Agent design point guarantees no Agent exceeds 100% capacity during any single-unit failure.

For larger deployments (1,000+ clients), scale horizontally with more Agents. The Mesh's matching cost scales roughly linearly with the number of Agent-client pairs, so a mesh of 10 Agents serving 1,000 clients is manageable without special tuning. Above that, partitioning the Mesh into segments (per-region, per-tenant) keeps the matching computation tractable.

When NOT to use VGMC

VGMC is the right pattern for resilience and capacity, but it is not the right pattern for every PTP deployment. Three situations where VGMC is unnecessary complexity.

• ●Single-site, single-Agent deployments with modest redundancy requirements. The Mesh and VGMC patterns assume multiple backing Agents; if you only have one, you're better off with a simpler grandmaster + BMCA fallback and no virtual endpoint.
• ●Deployments with strict grandmaster identity requirements where the downstream clients behave badly on Grandmaster identity changes. If the cost of re-locking on Grandmaster changes exceeds the benefit of seamless Mesh failover, classical A/B redundancy with a manual cutover procedure may be more appropriate.
• ●Extremely small scale — one or two downstream clients. The complexity of running a VGMC endpoint and a multi-Agent Mesh is not justified for a two-client deployment; point the clients directly at a single Agent and configure a secondary as manual BMCA fallback.

Sync Insight telemetry for VGMC deployments

For operators running VGMC deployments, Sync Insight surfaces three levels of observability. First, the backing Agent pool — each Agent's current state, which clients it's serving, its Mesh advertised capability. Second, the routing topology — the current mapping of downstream clients to backing Agents, the recent failover events, the Mesh's cost-model decisions. Third, the client-side view — per-client offset, path delay and holdover state, so operators can see whether any client is experiencing the Mesh transitions as user-visible offset discontinuities.

The usefulness is that a VGMC is more complex to run than a single grandmaster. The seamless-looking client experience is produced by a lot of machinery underneath, and operators need visibility into that machinery for capacity planning, incident investigation and compliance evidence. Sync Insight's VGMC dashboards cover all three layers and allow scroll-back through the attestation chain to any specific second.