Auto-detect network MTU to prevent BuildKit connectivity issues#101
Open
hemanthmantri wants to merge 1 commit intodrone-plugins:masterfrom
Open
Auto-detect network MTU to prevent BuildKit connectivity issues#101hemanthmantri wants to merge 1 commit intodrone-plugins:masterfrom
hemanthmantri wants to merge 1 commit intodrone-plugins:masterfrom
Conversation
## Problem BuildKit containers fail with network connectivity issues when the Docker daemon MTU doesn't match the host network MTU. This commonly occurs in: - Cloud environments (AWS, GCP, Azure) with VPCs/VPNs - VPN connections with reduced MTU - Corporate networks with custom MTU settings Symptoms include: - Connection timeouts during image pulls - Hanging builds with no error messages - npm ci failures in CI/CD pipelines ## Root Cause Docker daemon and BuildKit containers use default MTU (1500), but host network may have lower MTU (1450, 1400, etc.). Packets exceeding path MTU are dropped silently, causing mysterious failures. ## Solution 1. **Auto-detect host network MTU** on plugin startup 2. **Configure Docker daemon** with detected MTU via --mtu flag 3. **Inherit MTU in BuildKit containers** from daemon settings 4. **Maintain backward compatibility** - explicit PLUGIN_MTU overrides detection ## Implementation - **network.go**: New MTU detection using `net` stdlib package - **docker.go**: Auto-detect and apply MTU before daemon starts - **buildx.go**: Pass MTU to cmdSetupBuildx, log BuildKit MTU inheritance - **Tests**: Comprehensive coverage for detection, backward compat, priority ## Changes - `network.go` (+55 lines): MTU detection logic - `network_test.go` (+94 lines): Detection tests - `mtu_backward_compat_test.go` (+212 lines): Backward compatibility tests - `docker.go` (+13 lines): Auto-detection integration - `buildx.go` (+16 lines): MTU parameter handling ## Testing Checklist ### ✅ Unit Tests - [x] **TestDetectNetworkMTU** - Validates MTU detection works - [x] **TestGetEffectiveMTU** (3 cases) - Explicit vs auto-detect vs zero - [x] **TestGetEffectiveMTU_Priority** - Explicit MTU takes precedence ### ✅ Integration Tests - [x] **TestBackwardCompatibility_ExplicitMTU** - PLUGIN_MTU=1400 respected - [x] **TestBackwardCompatibility_AutoDetect** - Auto-detection when unset - [x] **TestBackwardCompatibility_DaemonDisabled** - No detection when disabled - [x] **TestBackwardCompatibility_CommandLine** (3 cases) - Command generation - [x] **TestBackwardCompatibility_EnvVarParsing** (3 cases) - Env var handling ### ✅ Test Coverage - All 12 MTU-related tests pass - All existing tests pass (no regressions) - `go test ./...` passes on all packages ## Behavior ### Before This Change - MTU always defaults to 1500 - No automatic adaptation to host network - Manual PLUGIN_MTU configuration required ### After This Change - MTU auto-detected from host network - Explicit PLUGIN_MTU still honored (takes precedence) - Daemon disabled: no detection (respects existing behavior) - BuildKit containers inherit from daemon ## Example Output ``` Auto-detected network MTU: 1450 (will be applied to Docker daemon and BuildKit containers) BuildKit will inherit MTU from Docker daemon: 1450 ``` ## Backward Compatibility ✅ **Fully backward compatible** - Existing `PLUGIN_MTU` configurations continue to work - Detection only happens when MTU not explicitly set - Daemon disabled mode unchanged - No breaking changes to configuration ## Impact - **Reduces mysterious network failures** in BuildKit - **Eliminates manual MTU configuration** in most cases - **Improves CI/CD reliability** in cloud and VPN environments - **Zero config change required** for existing users ## Related Issues Addresses BuildKit network connectivity issues in environments with non-standard MTU settings. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PLUGIN_MTUis not explicitly setPLUGIN_MTUvalues take precedence over auto-detectionWhy this matters
BuildKit containers inherit Docker daemon's default MTU (1500), but CI environments often use smaller MTU values (1460 on GCP, 1450 on AWS VPNs). This mismatch causes packet fragmentation and connectivity failures during
npm cior similar network-intensive operations.Test plan
network_test.go)mtu_backward_compat_test.go)PLUGIN_MTUstill takes precedence🤖 Generated with Claude Code