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.

Bug 1357026

Summary: Network team does not update vlan on mac address change
Product: Red Hat Enterprise Linux 7 Reporter: Juanjo Villaplana <villapla>
Component: NetworkManagerAssignee: Rashid Khan <rkhan>
Status: CLOSED DUPLICATE QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.2CC: atragler, bgalvani, lrintel, rkhan, thaller, villapla
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-07-17 08:10:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Juanjo Villaplana 2016-07-15 13:56:55 UTC
Description of problem:

When configuring an vlan interface over team interface, MAC address changes on the team interface aren't propagated to the vlan interface.

MAC address changes on team interfaces occur always on system boot, so vlan interfaces have always wrong MAC on boot (leading to traffic flooding issues).

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

NetworkManager-1.0.6-30.el7_2.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Add team interface

# nmcli connection add type team con-name team-test ifname team-test autoconnect no config '{"runner": {"name": "loadbalance"}}'
# nmcli connection modify team-test ipv4.method disabled ipv6.method ignore
# nmcli connection add type team-slave con-name team-test-port1 ifname ens192 master team-test
# nmcli connection add type team-slave con-name team-test-port2 ifname ens224 master team-test
# nmcli connection modify team-test connection.autoconnect yes

2. Add vlan interface

# nmcli connection add type vlan con-name vlan8 ifname vlan8 dev team-test id 8
# nmcli connection modify vlan8 ipv4.method disabled ipv6.method ignore

3. Restart system

# reboot

4. Check MAC addresses

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:50:56:b8:32:01 brd ff:ff:ff:ff:ff:ff
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team-test state UP mode DEFAULT qlen 1000
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff
4: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master team-test state UP mode DEFAULT qlen 1000
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff
5: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
    link/ether 00:50:56:b8:05:e8 brd ff:ff:ff:ff:ff:ff
6: team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff
7: vlan8@team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 12:88:41:cd:8a:0d brd ff:ff:ff:ff:ff:ff

Actual results:

6: team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff
7: vlan8@team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 12:88:41:cd:8a:0d brd ff:ff:ff:ff:ff:ff

Expected results:

6: team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff
7: vlan8@team-test: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT 
    link/ether 00:50:56:b8:1c:a3 brd ff:ff:ff:ff:ff:ff

Additional info:

This issue seems related to bz#1264322, bz#1281617, bz#1325752 and bz#1288412, but in this case related to team instead of bond interfaces.

Comment 2 Beniamino Galvani 2016-07-17 08:03:37 UTC
Hi,

the fix for bug 1264322 is generic for all VLANs over a software
device whose MAC address may change during initialization (due to
enslaving of lower interfaces). I can reproduce the issue with
NetworkManager-1.0.6-30; upgrading to the latest NetworkManager
version for RHEL 7.3 indeed solves the issue.

Probably it makes sense to mark this bug as duplicate of bug 1264322
as the underlying problem (and related fix) is the same.

*** This bug has been marked as a duplicate of bug 1264322 ***

Comment 3 Beniamino Galvani 2016-07-17 08:10:32 UTC
The existing bug for RHEL 7.3 was 1325752, sorry.

*** This bug has been marked as a duplicate of bug 1325752 ***