RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1857366 - RFE - Support VRF interfaces in nmstate
Summary: RFE - Support VRF interfaces in nmstate
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: nmstate
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.4
Assignee: Gris Ge
QA Contact: Mingyu Shi
URL:
Whiteboard:
Depends On:
Blocks: 1875967 1894575
TreeView+ depends on / blocked
 
Reported: 2020-07-15 17:40 UTC by Sebastian Scheinkman
Modified: 2021-05-18 15:17 UTC (History)
10 users (show)

Fixed In Version: nmstate-0.4.1-2.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-18 15:17:12 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github nmstate nmstate pull 1310 0 None closed vrf: Add support of Virtual Routing and Forwarding 2020-11-30 10:57:48 UTC

Description Sebastian Scheinkman 2020-07-15 17:40:00 UTC
Description of problem:

NetworkManager expose the know "vrf interfaces" at newer versions 
https://blogs.gnome.org/acardace/2020/05/08/networkmanager-1-24/

CNF network team will like to use kubernetes-nmstate to create VRF on the host level

Version-Release number of selected component (if applicable):

How reproducible:

There is no VRF in the nmstate schema so there is no way to configure it on hosts.


Actual results:


Expected results:


Additional info:

Comment 2 Edward Haas 2020-07-16 05:39:08 UTC
# 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.

Comment 3 Gris Ge 2020-09-30 03:51:44 UTC
Upstream has merged the patch.

Comment 8 Mingyu Shi 2020-10-28 03:24:41 UTC
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

Comment 9 Mingyu Shi 2020-10-28 05:58:10 UTC
A clarification: I mean both vrf0 and veth0 should be allowed to configure IP, track with: #bz1892178 and mark the current bug as verified

Comment 12 errata-xmlrpc 2021-05-18 15:17:12 UTC
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


Note You need to log in before you can comment on or make changes to this bug.