Bug 785666 - Client wouldn't report permanent HW addr. of slave interfaces for setups using network bonding
Client wouldn't report permanent HW addr. of slave interfaces for setups usin...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: subscription-manager (Show other bugs)
6.3
All Linux
high Severity medium
: rc
: ---
Assigned To: Adrian Likins
Entitlement Bugs
: Regression
Depends On: 543577
Blocks: 771481 840699
  Show dependency treegraph
 
Reported: 2012-01-30 04:03 EST by Miroslav Suchý
Modified: 2013-02-21 03:53 EST (History)
7 users (show)

See Also:
Fixed In Version: subscription-manager-1.1.4.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 543577
Environment:
Last Closed: 2013-02-21 03:53:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Miroslav Suchý 2012-01-30 04:03:25 EST
Subscription manager in RHEL (both in el6, el5) are affected by this:

+++ This bug was initially created as a clone of Bug #543577 +++

+++ This bug was initially created as a clone of Bug #517945 +++

Description of problem:
Client wouldn't report permanent HW addr. of slave interfaces for setups using
network bonding. Instead, registration and profile syncing would report
hardware address of first slave network interface for all other interfaces
involved in the bonding setup (just as HAL reports).

It would be desirable to report permanent hardware address instead.


Version-Release number of selected component (if applicable):
rhn-client-tools-0.7.10-1


How reproducible:
Always


Steps to Reproduce:
1. Create a client using network bonding
2. Register your client to Spacewalk
3. See what hardware addresses you see in machine's hardware profile card


Actual results:
Hardware profile card in Spacewalk webui shows HW address of first slave
network card for all other slaves involved in the bonding setup.


Expected results:
Hardware profile card in Spacewalk webui shows permanent HW address for
every slave involved in the bonding setup.


Additional information:
N/A

--- Additional comment from mzazrivec@redhat.com on 2009-12-02 11:58:01 EST ---

spacewalk.git master: fcaa4e5e75301f1faa2cf98fdbde1397924370bb

--- Additional comment from mzazrivec@redhat.com on 2010-02-05 07:49:47 EST ---

rhn-client-tools-0.8.2-1.el5

--- Additional comment from mmraka@redhat.com on 2010-02-16 07:58:44 EST ---

Spacewalk 0.8 has been released
Comment 9 Bryan Kearney 2012-10-30 09:53:58 EDT
This is not a blocker, and we would like to deliver this by SNAP1.
Comment 11 Adrian Likins 2012-10-30 16:39:33 EDT
Not sure I understand what the desired outcome of this bug is. 

Subscription-manager seem to report interface info for bonding interfaces if they
exist (python-ethtool finds them and we collect them). That info includes the MAC address of the created bonding interface (which seems to depend on what type of bonding is involved). 

for ex:

...
'net.interface.bond0.mac_address' : '52:54:00:07:03:BA'
'net.interface.eth0.ipv4_address' : 'Unknown'
'net.interface.eth0.ipv4_broadcast' : 'Unknown'
'net.interface.eth0.ipv4_netmask' : 'Unknown'
'net.interface.eth0.mac_address' : '52:54:00:07:03:BA'
'net.interface.eth1.ipv4_address' : 'Unknown'
'net.interface.eth1.ipv4_broadcast' : 'Unknown'
'net.interface.eth1.ipv4_netmask' : 'Unknown'
'net.interface.eth1.mac_address' : '52:54:00:66:20:F7'
...

The bug seems to be for rhn-client-tools...?
Comment 12 Adrian Likins 2012-10-30 17:01:47 EDT
I'll get a patch together that pulls in the rhn-client-tools /proc/net/bond parsing. I'm not sure we need it for our usage, though it shouldn't hurt anything.
Comment 13 Adrian Likins 2012-10-30 18:46:50 EDT
Ah, I see the case where the ethtool info is wrong (one case, "balance-rr" mode
bonding, where ifconfig/ethtool report all the slave interfaces as having the same address as the master bonding interface). 

I'm not really sure why reporting the info that ifconfig/ethool does is wrong though? For our case, I'm just stashing this info as "permanent_mac_address"
along with the ethtool reported info. I don't think either behavior really
affects subscription-manager much.
Comment 14 Adrian Likins 2012-11-01 09:28:46 EDT
commit afd8acf6e38c25933152b6a5526882a860a289ba
Author: Adrian Likins <alikins@redhat.com>
Date:   Wed Oct 31 10:12:33 2012 -0400

    785666: For bonded interfaces, find mac address of members
    
    For some modes of ethernet bonding, the mac address of
    the slaves of bonded devices are changed to match the
    mac address of the master. If we detect this scenario,
    also report the "permanent" mac address of the slave
    interfaces. This is a port of code from
    rhn-client-tools

Should land in 1.1.4 or later
Comment 16 Adrian Likins 2012-11-27 15:52:38 EST
setup steps

1. get a vm setup with two nics, you can add the second nic in the details view
of virt-manager. it can be the same setup as the existing one (vnet usually)

2. install system and get it setup as normal

3. Create a bond interface. You can do with with System->Preferences->Network Connections

  3a. Add a connection, choose "Bond" as the connnection type
  3b. On the "Editing Bond Connection" screen, choose "add" to
      add a new interface into the bonded interface
  3c. pick "wired", then add the mac address for eth0 in the
      "Device Mac Address" field, and ok. 
  3d. repeat for eth1

(alternatively, just copy the network config scripts here):

[root@dhcp129-16 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE="eth0"
MASTER="bond0"
SLAVE="yes"
BOOTPROTO="none"
HWADDR="52:54:00:07:03:BA"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
NM_CONTROLLED="no"
ONBOOT="no"
TYPE="Ethernet"
[root@dhcp129-16 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
MASTER=bond0
SLAVE=yes
HWADDR=52:54:00:66:20:F7
TYPE=Ethernet
ONBOOT=no
NM_CONTROLLED=no
BOOTPROTO=none
[root@dhcp129-16 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond0 
DEVICE=bond0
BONDING_OPTS="updelay=0 mode=balance-alb miimon=100 downdelay=0"
BONDING_MASTER=yes
MASTER=yes
BOOTPROTO=dhcp
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
ONBOOT=yes
MACADDR="00:22:44:66:03:BA"
NAME="Bond connection 1"

4. make sure "bonding" kernel module is loaded:

     modprobe bonding

(and then restart /etc/init.d/network)

5. You should now have a bond0 interface, in "adaptive-alb" mode with eth0
and eth1. ifconfig output should look something like:
[root@dhcp129-16 ~]# /sbin/ifconfig 
bond0     Link encap:Ethernet  HWaddr 52:54:00:07:03:BA  
          inet addr:10.13.129.16  Bcast:10.13.129.255  Mask:255.255.254.0
          inet6 addr: fe80::5054:ff:fe07:3ba/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:3876111 errors:0 dropped:356 overruns:0 frame:0
          TX packets:14339955 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:576653742 (549.9 MiB)  TX bytes:863987476 (823.9 MiB)

eth0      Link encap:Ethernet  HWaddr 52:54:00:07:03:BA  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1874686 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7168180 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:199556708 (190.3 MiB)  TX bytes:432768834 (412.7 MiB)
          Interrupt:11 Base address:0xc000 

eth1      Link encap:Ethernet  HWaddr 52:54:00:66:20:F7  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2001426 errors:0 dropped:356 overruns:0 frame:0
          TX packets:7171776 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:377097086 (359.6 MiB)  TX bytes:431218948 (411.2 MiB)
          Interrupt:11 

(you can also verify the bonding mode with cat /proc/net/bonding/bond0, look
for "Bonding Mode")

6. run subscription-manager facts --list

interfaces in the bond should report both a "mac_address" and a "permanent_mac_address". For the "adaptive-alb" case, each of the
eth* interfaces will have mac address that matches there permament_mac_address,
and the hwaddr of the bond0 interface will be one of the eth0 hwaddr.

7. switch bond mode to "round robin"

/sbin/ifdown bond0; echo balance-rr > /sys/class/net/bond0/bonding/mode ; /sbin/ifup bond0

8 run subscription-manager facts --list

now the bond0 interface will have a mac address, and the report mac_address
of eth0 and eth0 will be the same (and match that of the bond0) interface. The
permanent_mac_address should show the address of the card itself.
Comment 17 J.C. Molet 2012-11-27 16:54:12 EST
# rpm -qa | egrep "subscription|python-rhsm"
subscription-manager-1.1.6-1.el6.x86_64
subscription-manager-firstboot-1.1.6-1.el6.x86_64
python-rhsm-1.1.4-1.el6.x86_64
subscription-manager-gui-1.1.6-1.el6.x86_64


# subscription-manager facts --list | grep mac_address
net.interface.bond0.mac_address: 52:54:00:07:03:BA
net.interface.eth0.mac_address: 52:54:00:07:03:BA
net.interface.eth0.permanent_mac_address: 52:54:00:07:03:BA
net.interface.eth1.mac_address: 52:54:00:66:20:F7
net.interface.eth1.permanent_mac_address: 52:54:00:66:20:F7
net.interface.virbr0-nic.mac_address: 52:54:00:A0:27:4E
net.interface.virbr0.mac_address: 52:54:00:A0:27:4E

# cat /sys/class/net/bond0/bonding/mode
balance-alb 6

#/sbin/ifdown bond0; echo balance-rr > /sys/class/net/bond0/bonding/mode ;/sbin/ifup bond0

# cat /sys/class/net/bond0/bonding/mode
balance-rr 0

#  subscription-manager facts --list | grep mac_address
net.interface.bond0.mac_address: 52:54:00:07:03:BA
net.interface.eth0.mac_address: 52:54:00:07:03:BA
net.interface.eth0.permanent_mac_address: 52:54:00:07:03:BA
net.interface.eth1.mac_address: 52:54:00:07:03:BA
net.interface.eth1.permanent_mac_address: 52:54:00:66:20:F7
net.interface.virbr0-nic.mac_address: 52:54:00:A0:27:4E
net.interface.virbr0.mac_address: 52:54:00:A0:27:4E


shown above is eth1's listed mac address changed to bond0's (eth0's) mac address in round robin mode and has a differing permanent mac_address.

This also shows that the permanent_mac_address is now a new fact and that it is properly probed for.  Marking VERIFIED.
Comment 19 errata-xmlrpc 2013-02-21 03:53:52 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0350.html

Note You need to log in before you can comment on or make changes to this bug.