Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite 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 "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. 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 "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-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.
Description of problem:
Given a host that is using a tagged/bonded network, after being registered to Satellite, Satellite doesn't interpolate the facts correctly to make the NICs correct in the host info.
Version-Release number of selected component (if applicable):
6.4
How reproducible:
Easy
Steps to Reproduce:
1. build a host with a tagged/bonded network
2. register the host to Satellite
3. check the network interfaces of the host in Satellite
Actual results:
The NICs don't match the ones configured on the host
Expected results:
The NICs should match the ones on the host
Additional info:
No puppet is configured on the host. The output of `subscription-manager facts` is:
---
...
net.interface.bond0.3551.ipv4_address: 10.22.148.26
net.interface.bond0.3551.ipv4_address_list: 10.22.148.26
net.interface.bond0.3551.ipv4_broadcast: 10.22.151.255
net.interface.bond0.3551.ipv4_broadcast_list: 10.22.151.255
net.interface.bond0.3551.ipv4_netmask: 22
net.interface.bond0.3551.ipv4_netmask_list: 22
net.interface.bond0.3551.mac_address: D0:43:1E:62:6F:28
net.interface.bond0.mac_address: D0:43:1E:62:6F:28
net.interface.em1.mac_address: D0:43:1E:62:6F:28
net.interface.em1.permanent_mac_address: D0:43:1E:62:6F:28
net.interface.em2.mac_address: D0:43:1E:62:6F:2B
net.interface.em3.mac_address: D0:43:1E:62:71:FA
net.interface.em4.mac_address: D0:43:1E:62:71:FD
net.interface.em5.mac_address: D0:43:1E:62:6F:90
net.interface.em6.mac_address: D0:43:1E:62:6F:28
net.interface.em6.permanent_mac_address: D0:43:1E:62:6F:93
net.interface.em7.mac_address: D0:43:1E:62:77:B2
net.interface.em8.mac_address: D0:43:1E:62:77:B5
net.interface.lo.ipv4_address: 127.0.0.1
net.interface.lo.ipv4_address_list: 127.0.0.1
net.interface.lo.ipv4_broadcast: Unknown
net.interface.lo.ipv4_broadcast_list: Unknown
net.interface.lo.ipv4_netmask: 8
net.interface.lo.ipv4_netmask_list: 8
...
---
The hammer output is:
---
Network interfaces:
1) Id: 680
Identifier: bond0
Type: bond
MAC address: d0:43:1e:62:6f:28
FQDN:
2) Id: 675
Identifier: em2
Type: interface
MAC address: d0:43:1e:62:6f:2b
FQDN:
3) Id: 677
Identifier: em3
Type: interface
MAC address: d0:43:1e:62:71:fa
FQDN:
4) Id: 676
Identifier: em4
Type: interface
MAC address: d0:43:1e:62:71:fd
FQDN:
5) Id: 674
Identifier: em5
Type: interface
MAC address: d0:43:1e:62:6f:90
FQDN:
6) Id: 673
Identifier: em6
Type: interface (primary, provision)
MAC address: d0:43:1e:62:6f:28
FQDN: usmtnz-linfra02.dev.emrsn.org
7) Id: 679
Identifier: em7
Type: interface
MAC address: d0:43:1e:62:77:b2
FQDN:
8) Id: 678
Identifier: em8
Type: interface
MAC address: d0:43:1e:62:77:b5
FQDN:
---
In reality, the primary interface should be bond0.3551. em6 is just a slave of it.
Thanks Peter, the linked issue is expected to be fixed in an upcoming 6.7 release and looking at the code, it seems it should help in this case too. Matt can you please confirm with the customer once 6.7 is out and they upgrade to this version? I'm closing this for now as a duplicate, however if there's something not addressed by BZ 1528193, please reopen.
*** This bug has been marked as a duplicate of bug 1528193 ***
Description of problem: Given a host that is using a tagged/bonded network, after being registered to Satellite, Satellite doesn't interpolate the facts correctly to make the NICs correct in the host info. Version-Release number of selected component (if applicable): 6.4 How reproducible: Easy Steps to Reproduce: 1. build a host with a tagged/bonded network 2. register the host to Satellite 3. check the network interfaces of the host in Satellite Actual results: The NICs don't match the ones configured on the host Expected results: The NICs should match the ones on the host Additional info: No puppet is configured on the host. The output of `subscription-manager facts` is: --- ... net.interface.bond0.3551.ipv4_address: 10.22.148.26 net.interface.bond0.3551.ipv4_address_list: 10.22.148.26 net.interface.bond0.3551.ipv4_broadcast: 10.22.151.255 net.interface.bond0.3551.ipv4_broadcast_list: 10.22.151.255 net.interface.bond0.3551.ipv4_netmask: 22 net.interface.bond0.3551.ipv4_netmask_list: 22 net.interface.bond0.3551.mac_address: D0:43:1E:62:6F:28 net.interface.bond0.mac_address: D0:43:1E:62:6F:28 net.interface.em1.mac_address: D0:43:1E:62:6F:28 net.interface.em1.permanent_mac_address: D0:43:1E:62:6F:28 net.interface.em2.mac_address: D0:43:1E:62:6F:2B net.interface.em3.mac_address: D0:43:1E:62:71:FA net.interface.em4.mac_address: D0:43:1E:62:71:FD net.interface.em5.mac_address: D0:43:1E:62:6F:90 net.interface.em6.mac_address: D0:43:1E:62:6F:28 net.interface.em6.permanent_mac_address: D0:43:1E:62:6F:93 net.interface.em7.mac_address: D0:43:1E:62:77:B2 net.interface.em8.mac_address: D0:43:1E:62:77:B5 net.interface.lo.ipv4_address: 127.0.0.1 net.interface.lo.ipv4_address_list: 127.0.0.1 net.interface.lo.ipv4_broadcast: Unknown net.interface.lo.ipv4_broadcast_list: Unknown net.interface.lo.ipv4_netmask: 8 net.interface.lo.ipv4_netmask_list: 8 ... --- The hammer output is: --- Network interfaces: 1) Id: 680 Identifier: bond0 Type: bond MAC address: d0:43:1e:62:6f:28 FQDN: 2) Id: 675 Identifier: em2 Type: interface MAC address: d0:43:1e:62:6f:2b FQDN: 3) Id: 677 Identifier: em3 Type: interface MAC address: d0:43:1e:62:71:fa FQDN: 4) Id: 676 Identifier: em4 Type: interface MAC address: d0:43:1e:62:71:fd FQDN: 5) Id: 674 Identifier: em5 Type: interface MAC address: d0:43:1e:62:6f:90 FQDN: 6) Id: 673 Identifier: em6 Type: interface (primary, provision) MAC address: d0:43:1e:62:6f:28 FQDN: usmtnz-linfra02.dev.emrsn.org 7) Id: 679 Identifier: em7 Type: interface MAC address: d0:43:1e:62:77:b2 FQDN: 8) Id: 678 Identifier: em8 Type: interface MAC address: d0:43:1e:62:77:b5 FQDN: --- In reality, the primary interface should be bond0.3551. em6 is just a slave of it.