Bug 1857366

# Overview

Virtual routing and forwarding (VRF) is a technology that allows multiple instances of a routing table to co-exist within the same router at the same time.
In the telco industry it is commonly used to support multiple tenants with potentially overlapping IP subnets to share the same routing services.

At the end points, where the services run, VRF can be used to allow applications to serve tenants with layer 3 isolation by enabling separated routing tables
and binding of special interfaces to them.

# The Need

Serve multiple tenants with a single application, where each tenant is isolated by Layer 3 (IPv4/IPv6).
Such applications may run on bare metal, virtual machines and containers, on premise or in the cloud.

# Example

A simple setup scenario would consist of a Web server that needs to serve two or more tenants, each having overlapping IP subnets.
With the use of the VRF interfaces, the admin may create one interface for each tenant, assign it with a unique routing table each
and finally assign it as a parent of one of the existing NIC/s (or VLAN).
At the application side, one that is VRF aware will be able to bind to each VRF interface and serve each in isolation.
Applications that are not VRF aware, will most likely be instantiated once per each tenant and be bind to one VRF each.

For this scenario, consider the following configuration:

App0   App1   App2
 +      +      +
 |      |      |
 +      +      +
vrf0   vrf1   vrf2
 +      +      +
 |      |      |
 +      +      +
eth0   eth1   eth2

Where all vrfN interfaces have the same IP address (e.g. 10.10.10.1).
Depending on which ingress interface a request arrived, it will be served by the relevant application.

# Nmstate

Nmstate currently supports routing tables and rule configuration.
This RFE requests to add the VRF interface type to the supported interfaces, allowing both configuration and reporting.

Upstream has merged the patch.

With:
NetworkManager-1.28.0-0.1.el8.x86_64
nispor-0.6.1-2.el8.x86_64
nmstate-0.4.1-1.el8.noarch

It works well on configuration according to the vrf schema, but I think something is misunderstood. As I know, in a typical usage, we should configure ip address on a member port, not on vrf device itself. Since user often put multiply NIC into a vrf device, that makes no sense if you configure all the IPs on a single vrf device.

Take the below as an example:

---
interfaces:
- name: vrf0
  type: vrf
  state: up
  ipv4:
    enabled: false
    address: []
    dhcp: false
  ipv6:
    enabled: false
    address: []
    autoconf: false
    dhcp: false
  lldp:
    enabled: false
  mac-address: A2:A4:A6:6E:9F:8A
  mtu: 65536
  vrf:
    port:
    - veth0
    route-table-id: 100

we should configure ip on veth0, not vrf0. But if you try doing that with nmstate, an error comes out:
libnmstate.error.NmstateValueError: Interface veth0 is port of vrf interface vrf0 which does not allow port to have ipv6 enabled

A clarification: I mean both vrf0 and veth0 should be allowed to configure IP, track with: #bz1892178 and mark the current bug as verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nmstate bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1748