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.
Command 'ip xfrm state flush' triggers xfrm_state_flush() function in kernel (net/xfrm/xfrm_state.c). That function doesn't support filtering by address family.
Looking at iproute code, I see that 'ip xfrm state list' indeed supports filtering by address family. It uses XFRM_MSG_GETSA dump request internally. By adding an XFRMA_ADDRESS_FILTER attribute, one could add same functionality to 'ip xfrm state deleteall' command.
This is not a regression, right?
Hi,
(In reply to xmu from comment #3)
> yes, not a regresstion, rhel7.5 also has the same issue.
Thanks for clarification. I'll hereby make this a feature request and move to RHEL8.1 accordingly. Feel free to revert if you disagree.
Cheers, Phil
Fix sent upstream: https://marc.info/?l=linux-netdev&m=155654066930378&w=2
Xiumei, if time allows, could you please test if it fixes your issue? Note that you will have to use 'deleteall' instead of 'flush' and that by default, it will still remove both IPv4 and IPv6 entries. But specifying either of -4 or -6 flags will limit the effect to that address family.
Cheers, Phil
Hi Xiumei,
(In reply to xmu from comment #7)
> Phil,
> I'm much too busy doing rhel7.7 test recently, I'm not sure when I have
> time to do this, How about I test this when it goes to ON_QA?
Sure, no problem!
Upstream commit to backport:
commit cd21ae40130b4d1ddb3ef500800840e35e7bfad1
Author: Phil Sutter <phil>
Date: Mon May 6 19:09:56 2019 +0200
ip-xfrm: Respect family in deleteall and list commands
Allow to limit 'ip xfrm {state|policy} list' output to a certain address
family and to delete all states/policies by family.
Although preferred_family was already set in filters, the filter
function ignored it. To enable filtering despite the lack of other
selectors, filter.use has to be set if family is not AF_UNSPEC.
Signed-off-by: Phil Sutter <phil>
Signed-off-by: Stephen Hemminger <stephen>
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, 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-2019:3602