Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Created attachment 1843563[details]
Diff of the failed configuration
Created attachment 1843563[details]
Diff of the failed configuration
Description of problem:
When any VLAN filtering is configured on Intel X710, the configuration fails to get applied, with dmesg containing a number of following messages:
[79627.840049] i40e 0000:19:00.1: Error I40E_AQ_RC_ENOSPC adding RX filters on PF, promiscuous mode forced on
The odd part is that it happens even with a single VLAN trunk getting open, so it **should** not be a problem with lack of memory.
Version-Release number of selected component (if applicable):
RHEL 8.4
nmstate 1.0.2-14
NetworkManager in container, version 1.30.0-13.el8_4
NetworkManager on the host, version 1.30.0-10.el8_4
How reproducible:
Consistently on some PFs of the NIC. It always happens on the second one but did not happen on the third. While the second one had a wire connected, third one was disconnected.
Steps to Reproduce:
1. Get a host with Intel X710 NIC
2. Apply the following config:
interfaces:
- bridge:
options:
stp:
enabled: false
port:
- name: eno2
vlan:
mode: trunk
trunk-tags:
- id: 1000
ipv4:
auto-dns: true
dhcp: false
enabled: false
ipv6:
enabled: false
name: br1test
state: up
type: linux-bridge
Actual results:
Configuration fails, nmstate notices that requested VLANs were not applied. dmesg contains number of messages complaining about I40E_AQ_RC_ENOSPC. The number depends on how many IDs we atttemped to open.
Expected results:
We should be able to apply at least a limited numbed of trunk IDs on hardware that has offloading capability.
Additional info:
This reproduces even if vlan offloading gets disabled through ethtool:
rx-vlan-offload: off
tx-vlan-offload: off
Used NICs:
[root@cnv-qe-infra-32 /]# lspci | grep 710
19:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
19:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
19:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
19:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)
Comment 2Fernando F. Mancera
2021-11-25 11:09:19 UTC
Debugging with nmcli and iproute2. I think this is probably a NM or kernel bug.
After reboot of the host and trying again, the dmesg stopped appearing (is restart needed to clear the memory?). However, it still fails to configure the VLAN trunk.
It's not clear that these two bugs are the same to me. Despite being in the same area, they are different. The on with Pensando caused the host to freeze. This Intel one just silently ignores the configuration. Marking it as a duplicate would be dangerous as we would skip the investigation and just assume it is already fixed. Could we move the BZ to kernel and let them evaluate it instead?
(In reply to Gris Ge from comment #20)
> Hi nijin ashok,
>
> Could you use above scratch rpm to test in your environment?
>
> Thank you!
Tested with the new build and nmstatectl was able to apply the VLANs successfully.
~~~
npc iface ens1f0 |grep -A8 vlans
Unhandled AF_SPEC_BRIDGE_INFO: 0 [2, 0]
Unhandled AF_SPEC_BRIDGE_INFO: 1 [1, 0]
Unhandled AF_SPEC_BRIDGE_INFO: 0 [2, 0]
Unhandled AF_SPEC_BRIDGE_INFO: 1 [1, 0]
vlans:
- vid: 1
is_pvid: true
is_egress_untagged: true
- vid_range:
- 100
- 2412
is_pvid: false
is_egress_untagged: false
~~~
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 (nispor 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/RHEA-2022:1881