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 1884038[details]
reproducer.sh
Description of problem:
Sometimes the interface still hold (link-local) ipv6 when it attached to a bridge.
It easily happens when running a script. In the attachment script, if you add "sleep 2" before run "nmstatectl apply", it can't reproduce.
Version-Release number of selected component (if applicable):
nmstate-2.1.1-0.alpha.20220519.437e4a9.el9.x86_64
NetworkManager-1.39.5-1.el9.x86_64
Linux dell-per740-61.rhts.eng.pek2.redhat.com 5.14.0-96.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 19 07:21:30 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
DISTRO=RHEL-9.1.0-20220524.0
How reproducible:
nearly 100%
Steps to Reproduce:
Run the script it the attachment
Actual results:
[13:24:48@dell-per740-61 ~]0# ip -6 addr
356: veth0_ep@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::70e1:baff:fe33:8fbe/64 scope link noprefixroute
valid_lft forever preferred_lft forever
357: veth0@veth0_ep: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::4c86:e8ff:fe61:bf9b/64 scope link
valid_lft forever preferred_lft forever
358: veth1_ep@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::30c8:b9ff:fec9:7932/64 scope link noprefixroute
valid_lft forever preferred_lft forever
359: veth1@veth1_ep: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::3811:7fff:fe0f:8803/64 scope link
valid_lft forever preferred_lft forever
360: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::4c86:e8ff:fe61:bf9b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Expected results:
The IPs on veth0 and veth1 should be removed as they've attached to br0.
Additional info:
Before run "nmstatectl apply", if configured any ipv4 or ipv6 on, for example, veth1, then the all IP of veth1 would be removed at attaching, as expected.
This never happened on RHEL 8, but easily to reproduce on RHEL 9.1 with rust
Created attachment 1884038 [details] reproducer.sh Description of problem: Sometimes the interface still hold (link-local) ipv6 when it attached to a bridge. It easily happens when running a script. In the attachment script, if you add "sleep 2" before run "nmstatectl apply", it can't reproduce. Version-Release number of selected component (if applicable): nmstate-2.1.1-0.alpha.20220519.437e4a9.el9.x86_64 NetworkManager-1.39.5-1.el9.x86_64 Linux dell-per740-61.rhts.eng.pek2.redhat.com 5.14.0-96.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 19 07:21:30 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux DISTRO=RHEL-9.1.0-20220524.0 How reproducible: nearly 100% Steps to Reproduce: Run the script it the attachment Actual results: [13:24:48@dell-per740-61 ~]0# ip -6 addr 356: veth0_ep@veth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::70e1:baff:fe33:8fbe/64 scope link noprefixroute valid_lft forever preferred_lft forever 357: veth0@veth0_ep: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::4c86:e8ff:fe61:bf9b/64 scope link valid_lft forever preferred_lft forever 358: veth1_ep@veth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::30c8:b9ff:fec9:7932/64 scope link noprefixroute valid_lft forever preferred_lft forever 359: veth1@veth1_ep: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::3811:7fff:fe0f:8803/64 scope link valid_lft forever preferred_lft forever 360: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 fe80::4c86:e8ff:fe61:bf9b/64 scope link noprefixroute valid_lft forever preferred_lft forever Expected results: The IPs on veth0 and veth1 should be removed as they've attached to br0. Additional info: Before run "nmstatectl apply", if configured any ipv4 or ipv6 on, for example, veth1, then the all IP of veth1 would be removed at attaching, as expected. This never happened on RHEL 8, but easily to reproduce on RHEL 9.1 with rust