VM replication initial sync stuck due to network MTU mismatch

Products

VMware Live Recovery

Issue/Introduction

Initial sync for VM replication may become stuck in a "Not Active" state or "Initial Sync" state. This behavior typically indicates network path limitations, specifically MTU (Maximum Transmission Unit) configuration mismatches preventing successful bulk data transfer.

Symptoms:

VM replication initial sync remains at a fixed percentage (e.g., 48%, 82%) for an extended period.

In some cases, 'Disk size mismatch' error message is reported:

A replication error occurred at the vSphere Replication Server for replication '<VM_name>'. Details: 'No connection to VR Server for virtual machine <VM_name> on host <FQDN> in cluster <Cluster_name> in <Datacenter_name>: Disk size mismatch'.
The VM is newly added to Replication and initial sync is running on it.

Environment

vSphere Replication 9.x

Cause

The replication task fails when MTU settings (e.g., Jumbo Frames set to 9000) are mismatched along the network path. While smaller packets (metadata) traverse successfully, bulk data transfers are silently dropped by intermediate network devices that do not support the larger frame size, causing the sync to hang.

Cause Validation:

In case of enhanced replication, below events will be observed in the source ESXi host /var/log/vmkernel.log file

2026-02-19T06:33:27.3802 Wa (180) vmkwarning: cpull: 6507409) WARNING: Hbr: 788: Failed to receive from 127. 0.0.1 (groupID-GID-672ed7f0-7066-####-####-############) : Broken pipe

The /var/log/hbr-agent.log file on the source ESXi host reveals that it is unable to write the data to the target ESXi host and the connections are timing out

2026-02-19T06:33:27.3972 In (166) hbr-agent-bin[6235489] : [0x000000aac94b1700] info: [Proxy [Group: GID-672ed7f0-7066-####-####-############] -> [10.#.#.#: 32032]] Bound to vmk: vmk2 for connection to 10.#.#.#: 32032
2026-02-19T06:33:27.397Z In(166) hbr-agent-bin[6235489]: [0x000000aac9532700] info: [Proxy [Group: GID-672ed7f0-7066-####-####-############] -> [10.#.#.#: 32032]] TCP Connect latency was 505us
2026-02-19T06:35:43.433Z In (166) hbr-agent-bin[6235489]: [0x000000aac9532700] error: [Proxy [Group: GID-672ed7f0-7066-####-####-############] -> [10.#.#.#: 32032] ] Failed to write to server: Broken pipe
2026-02-19T06:35:43.434Z In(166) hbr-agent-bin[6235489]: [0x000000aac9430700] error: [Proxy [Group: GID-672ed7f0-7066-####-####-############] -> [10.#.#.#: 32032]] Failed to read from server: Connection timed out

In addition to this, validating the connectivity between the ESXi host and VR appliance (legacy replication) or between the source and target ESXi host (enhanced replication) reveals packet loss.

Syntax: vmkping -I vmk# -s MTU -d <Destination Appliance IP Address>

Example 1: In case replicating vmkernel interface is using MTU 9000, run vmkping using the below example format and check if there is a packet loss.

vmkping -I vmk2 -s 8972 -d <Destination Appliance IP Address>
PING #.#.#.# (10.#.#.#): 8972 data bytes

- #.#.#.# ping statistics
3 packets transmitted, 0 packets received, 100% packet loss

Example 2: In case replicating vmkernel interface is using MTU 1500 run vmkping using the below example format and check if there is a packet loss.

vmkping -I vmk2 -s 1472 -d <Destination Appliance IP Address>
PING #.#.#.# (#.#.#.#): 1472 data bytes

- #.#.#.# ping statistics
3 packets transmitted, 0 packets received, 100% packet loss

Resolution

Standardize MTU settings across the entire network path.
Configure MTU to 1500 on all source and destination ESXi host interfaces used for replication traffic.
If replication traffic requires Jumbo Frames, coordinate with the networking team to ensure all switches and routers in the path support the configured MTU.
Monitor replication task. Synchronization should resume automatically once the network path supports the frame size.