Parent folderOpen Confluence

RWS Architecture article

OpenShift Multiple Networks VRF Plugin (Summary)

Summary of OpenShift Container Platform multiple-network documentation for virtual routing and forwarding (VRF) on pod secondary networks.

  1. Typesource
  2. Statusactive
  3. Domainopenshift
On this page
  1. Source - OpenShift Multiple Networks VRF Plugin
  2. Overview
  3. Context
  4. Decisions
  5. Current State
  6. References
  7. Future Work
  8. Related

Source - OpenShift Multiple Networks VRF Plugin

Overview

Summary of OpenShift Container Platform multiple-network documentation for virtual routing and forwarding (VRF) on pod secondary networks.

Context

This source is relevant where tenant or CNF workloads need overlapping address spaces, secondary-network segmentation, and Linux VRF-based traffic isolation inside pods.

Decisions

  • Use this source as the baseline for pod-level VRF behavior and constraints in OpenShift.
  • Keep pod-level VRF guidance separate from datacenter EVPN VRF guidance; they solve related but different layers of the design.

Current State

  • VRF on secondary pod networks provides workload isolation and multi-tenancy with unique routing tables per VRF domain.
  • CNO-managed Network CRs create NetworkAttachmentDefinition objects; generated NADs are not manually edited.
  • VRF plugin usage requires a plugins chain where the underlying secondary network plugin is declared first and the vrf plugin second.
  • VRF behavior is valid only with netdevice resources.
  • Applications use direct interface binding (for example SO_BINDTODEVICE) to select the VRF path; ip vrf exec is not supported in pods.
  • Operational implications include capability requirements (for example CAP_NET_RAW where needed), explicit routing-table ownership, and verification via ip vrf show and ip link.
  • Architecture interpretation in this vault: VRF plugin behavior is pod/host-network local and does not define datacenter EVPN route policy by itself; external VRF exposure still requires explicit border or FRR policy controls.
  • Architecture interpretation in this vault: route leaking between workload VRFs must be deliberate and auditable; implicit tenant-to-tenant reachability is not baseline behavior.

References

Future Work

  • Re-validate plugin and API details against the target OpenShift release in scope before production rollout.
  • Add a vault runbook that maps VRF plugin fields (vrfname, table) to intent data ownership and evidence capture.
  • Add a mapping table from OpenShift VRF objects to datacenter EVPN RT policy so tenant boundary behavior is consistent end-to-end.

Related