XML

Word

Printable

<--- Cut-n-Paste the entire contents of this description into your new Epic --->

Epic Goal

Why is this important?

VRF configurations are used where strict Layer3 network isolation is required, either because of security or business reasons.

Any Pod running on a node that has a NIC with an IP that connects to an "private network" will be able to send traffic to that network just by being in the same node because the path will be Pod > OVS/OVN > Host Routing Table > "private network". A node level VRF configuration will prevent this scenario
Customers with networks with overlapping CIDRS (e.g. OAM network & storage network connecting to the same node and having overlapping CIDRS). Even if those networks are used for IPvlans or Macvlans interfaces and another for host access, that configuration is only possible by isolating one of them with a VRF

CI - MUST be running successfully with tests automated
Release Technical Enablement - Provide necessary release enablement details and documents.
...

NMState already has support for this functionality. If everything works as expected, we should just need to test and document the feature.

CI - CI is running, tests are automated and merged.
Release Enablement <link to Feature Enablement Presentation>
DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
DEV - Downstream build attached to advisory: <link to errata>
QE - Test plans in Polarion: <link or reference to Polarion>
QE - Automated tests merged: <link or reference to automated tests>
DOC - Downstream documentation merged: <link to meaningful PR>