Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-19142

Cannot set the VLAN flags, so macvlan on top of vlan doesn't work as it should

XMLWordPrintable

    • nmstate-2.2.21-1.el9
    • None
    • 1
    • rhel-sst-network-management
    • ssg_networking
    • 22
    • 1
    • False
    • Hide

      None

      Show
      None
    • Yes
    • NMT - RHEL 8.10/9.4 DTM 18-20
    • Hide

      As a network administrator,
      I want the ability to specify VLAN flags in the Node Network Configuration Policy (NNCP) using nmstate,
      So that I can have more control over VLAN behavior, such as packet handling and header reordering, to ensure optimal network performance and compatibility in my infrastructure.

      Given a system administrator using nmstate to configure network settings,
      When they add a "flags" field to the VLAN configuration in a Node Network Configuration Policy (NNCP),
      Then the system should successfully accept and apply the "flags" field with the specified values.

      Definition of Done:

      • The implementation meets the acceptance criteria
      • Unit test and integration test are written and pass
      • The code is part of a build attached to an errata
      Show
      As a network administrator, I want the ability to specify VLAN flags in the Node Network Configuration Policy (NNCP) using nmstate, So that I can have more control over VLAN behavior, such as packet handling and header reordering, to ensure optimal network performance and compatibility in my infrastructure. Given a system administrator using nmstate to configure network settings, When they add a "flags" field to the VLAN configuration in a Node Network Configuration Policy (NNCP), Then the system should successfully accept and apply the "flags" field with the specified values. Definition of Done: The implementation meets the acceptance criteria Unit test and integration test are written and pass The code is part of a build attached to an errata
    • Pass
    • None
    • Enhancement
    • Hide
      .Introduction of new `nmstate` attributes for the VLAN interface

      With this update of the `nmstate` framework, the following VLAN attributes were introduced:

      * `registration-protocol`: VLAN Registration Protocol. The valid values are `gvrp` (GARP VLAN Registration Protocol), `mvrp` (Multiple VLAN Registration Protocol), and `none`.
      * `reorder-headers`: reordering of output packet headers. The valid values are `true` and `false`.
      * `loose-binding`: loose binding of the interface to the operating state of its primary device. The valid values are `true` and `false`.

      Your YAML configuration file can look similar to the following example:

      ----
      ---
      interfaces:
        - name: eth1.101
          type: vlan
          state: up
          vlan:
            base-iface: eth1
            id: 101
            registration-protocol: mvrp
            loose-binding: true
            reorder-headers: true
      ----
      Show
      .Introduction of new `nmstate` attributes for the VLAN interface With this update of the `nmstate` framework, the following VLAN attributes were introduced: * `registration-protocol`: VLAN Registration Protocol. The valid values are `gvrp` (GARP VLAN Registration Protocol), `mvrp` (Multiple VLAN Registration Protocol), and `none`. * `reorder-headers`: reordering of output packet headers. The valid values are `true` and `false`. * `loose-binding`: loose binding of the interface to the operating state of its primary device. The valid values are `true` and `false`. Your YAML configuration file can look similar to the following example: ---- --- interfaces:   - name: eth1.101     type: vlan     state: up     vlan:       base-iface: eth1       id: 101       registration-protocol: mvrp       loose-binding: true       reorder-headers: true ----
    • Done
    • None

      What were you trying to do that didn't work?

      I was trying to connect from one pod to another one in OpenShift using an additional network, but when the pods are in the same host they cannot connect.

      The NetworkAttachmentDefinition is using a macvlan (default bridge mode) on top of a vlan defined in an nncp.

      The investigation indicates that the issue is that the vlan is created with the "reorder_hdr" set to "off", preventing the vlan from redirecting packages between pods on the same host.

      The VLAN was created with an nncp similar to this one:

      apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: gorka
spec:
  desiredState:
    interfaces:
    - name: enp6s0.102
      description: testing VLAN using enp6s0
      type: vlan
      state: up
      vlan:
        base-iface: eenp6s0
        id: 102 

       

      And when we look at the interface we can see that <REORDER_HDR> is not there

      $ ip -detail a show enp6s0.102
244: enp6s0.102@enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:70:fa:d9 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 0 maxmtu 65535
    vlan protocol 802.1Q id 102 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

       

      The issue stems from the default value when using the D-Bus API is disabling the reordering (unlike when creating things manually) and we don't have a way to change this value to enable it.

      The default value of "vlan.flags" is described in the NetworkManager documentation and we can see it in the vlan that gets created:

      $ sudo nmcli c show enp6s0.102|grep vlan
connection.type:                        vlan
vlan.parent:                            fe02f3e7-bb18-360e-b183-2c7f814f219d
vlan.id:                                102
vlan.flags:                             0 (NONE)
vlan.protocol:                          --
vlan.ingress-priority-map:              --
vlan.egress-priority-map:               --

       

      The ask would be to either change the default or allowing passing of "vlan.flags" at the nncp level so that a macvlan on top of vlan allows pods within the same host to communicate with one another.

      Please provide the package NVR for which bug is seen:

      This was tried on an OpenShift local version 4.13.0 with the following versions:
         handlerNmstateVersion: nmstatectl 2.2.12
         hostNetworkManagerVersion: 1.42.2

      How reproducible:

      Always.

      Steps to reproduce

      1. Create an nncp to create a vlan
      2. Create a nad to have a macvlan interface on top of the vlan
      3. Create a couple of pods on the same OpenShift host with that nad

      Another way to reproduce it is creating the vlan with nncp and then manually creating 2 network namespaces, creating 2 macvlans on top of the vlan, assign one macvlan to each nw namespace, and then try to ping from one namespace to the other.

      Expected results

      One pod can ping the other using that interface IP address

      Actual results

      There is no connectivity between the 2 pods.

              fge@redhat.com Gris Ge
              geguileo@redhat.com Gorka Eguileor
              Felix Enrique Llorente Pastora Felix Enrique Llorente Pastora
              Mingyu Shi Mingyu Shi
              Jaroslav Klech Jaroslav Klech
              Votes:
              0 Vote for this issue
              Watchers:
              20 Start watching this issue

                Created:
                Updated:
                Resolved: