[PR #1371] [CLOSED] [TE] filter the local network interface

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

kvcache-ai/Mooncake#2201

bsakaguchi commented

2026-10-29 21:33:32 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/Mooncake/pull/1371
Author: @cocktail828
Created: 1/13/2026
Status: ❌ Closed

Base: main ← Head: feat/host_passthrouth

📝 Commits (1)

12b4284 [TE] filter the local network interface

📊 Changes

3 files changed (+107 additions, -96 deletions)

View changed files

📝 mooncake-transfer-engine/include/transfer_metadata_plugin.h (+13 -12)
📝 mooncake-transfer-engine/src/transfer_engine_impl.cpp (+7 -1)
📝 mooncake-transfer-engine/src/transfer_metadata_plugin.cpp (+87 -83)

📄 Description

Description

Type of Change

Types
- Bug fix
- New feature
  - Transfer Engine
  - Mooncake Store
  - Mooncake EP
  - Integration
  - P2P Store
  - Python Wheel
- Breaking change
- CI/CD
- Documentation update
- Other

Summary

This PR(by iflytek) improves the reliability and correctness of RPC metadata population.
In multi-NIC, containerized, or virtualized environments, automatic interface selection can inadvertently choose non-routable or internal addresses—such as 127.0.0.1 (loopback) or 172.21.0.1 (Docker bridge)—leading to RPC endpoints that are unreachable from remote peers. By prioritizing user-specified addresses, we ensure the transport layer binds to the intended network interface.

Rationale

User intent takes precedence: In TCP-based deployments, users typically specify the desired IP or hostname explicitly (e.g., via configuration or CLI flags). The system should respect this input rather than overriding it with auto-discovered interfaces.
Auto-detection risks incorrect bindings:
Automatic IP/interface selection may pick:
- 127.0.0.1 or ::1 — only reachable locally
- Docker-managed addresses like 172.21.0.1 — isolated to container networks
- Virtual NICs (e.g., veth, br-xxx) — not externally routable
  These choices can cause RPC servers to bind to interfaces that remote clients cannot access, resulting in silent connectivity failures.

Checklist

I have performed a self-review of my own code.
I have updated the documentation.
I have added tests to prove my changes are effective.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/Mooncake/pull/1371 **Author:** [@cocktail828](https://github.com/cocktail828) **Created:** 1/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `feat/host_passthrouth` --- ### 📝 Commits (1) - [`12b4284`](https://github.com/kvcache-ai/Mooncake/commit/12b428469b35b4ba2908688bf65ee54ae6a6bfba) [TE] filter the local network interface ### 📊 Changes **3 files changed** (+107 additions, -96 deletions) <details> <summary>View changed files</summary> 📝 `mooncake-transfer-engine/include/transfer_metadata_plugin.h` (+13 -12) 📝 `mooncake-transfer-engine/src/transfer_engine_impl.cpp` (+7 -1) 📝 `mooncake-transfer-engine/src/transfer_metadata_plugin.cpp` (+87 -83) </details> ### 📄 Description ## Description  ## Type of Change * Types - [x] Bug fix - [x] New feature - [x] Transfer Engine - [ ] Mooncake Store - [ ] Mooncake EP - [ ] Integration - [ ] P2P Store - [ ] Python Wheel - [ ] Breaking change - [ ] CI/CD - [ ] Documentation update - [ ] Other ## Summary This PR(by iflytek) improves the reliability and correctness of RPC metadata population. In multi-NIC, containerized, or virtualized environments, automatic interface selection can inadvertently choose non-routable or internal addresses—such as 127.0.0.1 (loopback) or 172.21.0.1 (Docker bridge)—leading to RPC endpoints that are unreachable from remote peers. By prioritizing user-specified addresses, we ensure the transport layer binds to the intended network interface. ## Rationale 1. User intent takes precedence: In TCP-based deployments, users typically specify the desired IP or hostname explicitly (e.g., via configuration or CLI flags). The system should respect this input rather than overriding it with auto-discovered interfaces. 2. Auto-detection risks incorrect bindings: Automatic IP/interface selection may pick: - 127.0.0.1 or ::1 — only reachable locally - Docker-managed addresses like 172.21.0.1 — isolated to container networks - Virtual NICs (e.g., veth, br-xxx) — not externally routable These choices can cause RPC servers to bind to interfaces that remote clients cannot access, resulting in silent connectivity failures. ## Checklist - [x] I have performed a self-review of my own code. - [ ] I have updated the documentation. - [ ] I have added tests to prove my changes are effective. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

closed this issue
added the
pull-request
label

Rows
Columns

[PR #1371] [CLOSED] [TE] filter the local network interface #2201