From 70037d5aedcf45f8229b21231002f1ddda728a6e Mon Sep 17 00:00:00 2001 From: Markus Fensterer Date: Wed, 1 Apr 2026 15:04:26 +0200 Subject: [PATCH 1/2] draft for network peering MEP --- community/04-Proposals/MEP20/README.md | 136 +++++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 community/04-Proposals/MEP20/README.md diff --git a/community/04-Proposals/MEP20/README.md b/community/04-Proposals/MEP20/README.md new file mode 100644 index 0000000..00ef20d --- /dev/null +++ b/community/04-Proposals/MEP20/README.md @@ -0,0 +1,136 @@ +--- +slug: /MEP-20-network-peering +title: MEP-20 +sidebar_position: 20 +--- + +# Network Peering + +## **Summary** + +This MEP proposes a **Network Peering** feature for `metal-stack` to enable direct routing between private networks of a project, shared networks, and external networks without traversing a firewall. This enhances flexibility for east-west traffic, zone-aware routing, and firewall-less deployments while maintaining security constraints. + +## **Motivation** + +Private networks in `metal-stack` are isolated in **VRFs (Virtual Routing and Forwarding)**, ensuring multi-tenancy and security. Access to other networks is controlled by firewalls, which may introduce unnecessary overhead in certain scenarios: + +1. **Direct Storage Access** + - There is already the feature of **shared networks** that can be used in cases where traffic should only pass one firewall btw source and desination. + - With this new feature firewall traversal could be eliminated completly. +2. **Cluster-to-Cluster Communication** + - Enable direct routing between private networks (e.g., Kubernetes clusters) without firewall intervention. +3. **Zone-Aware Routing** + - Keep traffic local within a datacenter (e.g., storage access) instead of routing across zones (e.g. over a remote firewall and back to local storage). +4. **Firewall-Less Deployments** + - Directly expose internet-facing services (e.g., IPv6 nodes) without a firewall. +5. **Enterprise/ISP Peering** + - (Optional) Allow peering with external networks (e.g., corporate networks, ISPs). + +### **Current Limitations** + +- All inter-network traffic must pass through a firewall. +- No native support for direct VRF-to-VRF routing. +- No zone-aware routing for storage or cluster traffic. + +## **Proposal** + +Introduce a **Network Peering** mechanism that allows controlled routing between: + +- Private networks within the **same project**. +- Private networks and **shared private networks**. +- Private networks and **external networks** (e.g., internet, enterprise networks). + +### **Constraints** + +- **No cross-project peering** (security boundary). +- **No transitive peering** (peering must be explicitly configured). + +## **Design** + +### **1. New Entity: `Peering`** + +A new `peering` resource will be introduced in `metal-api` and `metalctl`: + +```yaml +apiVersion: metal-stack.io/v1 +kind: Peering +metadata: + name: privnet1-to-storage +spec: + network1: privnet1-id + network2: storage-id + peeringType: local # local for peering VRFs at leaf switches, external for peering a with an external peer + # Optional: BGP peering for external peering + bgp: + local: + as: 65000 + cidr: 172.16.0.1/30 + port: "Ethernet0@exit01" + remote: + as: 65001 + cidr: 172.16.0.2/30 +``` + +### **2. CLI Commands** + +```bash +# Create a peering between two private networks +metalctl network peering create --network1 privnet1 --network2 privnet2 + +# Create a peering between a private and shared network +metalctl network peering create --network1 privnet1 --network2 storage + +# Create a peering between a private network and the internet +metalctl network peering create --network1 privnet1 --network2 internet + +# (Optional) BGP peering with an external network +metalctl network peering create \ + --network1 internet \ + --localAs 65000 \ + --localCidr 172.16.0.1 \ + --localPort Ethernet0@exit01 \ + --remoteAs 65001 \ + --remoteCidr 172.16.0.2 +``` + +### **3. Implementation in `metal-core`** + +- **VRF Route Exchange**: Configure route exchange between VRFs on the leaf switches. +- **Security Policies**: Ensure no cross-project leaks. +- **Zone Awareness**: Prefer local routes over inter-zone routes. + +### **4. Auto-Peering (Optional)** + +- If a project has the label `auto-peer: "true"`, all its private networks can peer with each other. +- Requires additional validation to prevent misconfigurations. + +## **Impact** + +### **Positive** + +- **Performance**: Reduces latency for east-west traffic. +- **Flexibility**: Enables new deployment models (e.g., firewall-less clusters). +- **Zone Awareness**: Keeps storage traffic local. + +### **Negative** + +- **Complexity**: Adds new configuration options. +- **Security Risks**: Misconfigurations could expose networks. +- **Operational Overhead**: Requires monitoring for route leaks. + +## **Implementation Plan** + +1. **Phase 1**: Add `Peering` entity to `metal-api` and `metalctl`. +2. **Phase 2**: Implement VRF route exchange in `metal-core`. +3. **Phase 3**: Add auto-peering (optional). +4. **Phase 4**: Support external BGP peering (if approved). + +## **References** + +- [Shared Networks MEP](https://github.com/metal-stack/metal-stack/blob/main/docs/meps/MEP-XXXX-shared-networks.md) +- [VRF Isolation in metal-stack](https://docs.metal-stack.io/stable/architecture/networking/) +- [BGP Peering Best Practices](https://tools.ietf.org/html/rfc7938) + +## **Conclusion** + +This MEP enables **secure, flexible network peering** in `metal-stack`, addressing key use cases while maintaining security boundaries. From fe9c529ccdb2c9b752b76f2cd72cbd20729354ae Mon Sep 17 00:00:00 2001 From: Markus Fensterer Date: Wed, 1 Apr 2026 15:11:31 +0200 Subject: [PATCH 2/2] fix spelling --- community/04-Proposals/MEP20/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/community/04-Proposals/MEP20/README.md b/community/04-Proposals/MEP20/README.md index 00ef20d..7e7f609 100644 --- a/community/04-Proposals/MEP20/README.md +++ b/community/04-Proposals/MEP20/README.md @@ -15,8 +15,8 @@ This MEP proposes a **Network Peering** feature for `metal-stack` to enable dire Private networks in `metal-stack` are isolated in **VRFs (Virtual Routing and Forwarding)**, ensuring multi-tenancy and security. Access to other networks is controlled by firewalls, which may introduce unnecessary overhead in certain scenarios: 1. **Direct Storage Access** - - There is already the feature of **shared networks** that can be used in cases where traffic should only pass one firewall btw source and desination. - - With this new feature firewall traversal could be eliminated completly. + - There is already the feature of **shared networks** that can be used in cases where traffic should only pass one firewall btw source and destination. + - With this new feature firewall traversal could be eliminated completely. 2. **Cluster-to-Cluster Communication** - Enable direct routing between private networks (e.g., Kubernetes clusters) without firewall intervention. 3. **Zone-Aware Routing**