Bug 785666
Summary: | Client wouldn't report permanent HW addr. of slave interfaces for setups using network bonding | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Miroslav Suchý <msuchy> |
Component: | subscription-manager | Assignee: | Adrian Likins <alikins> |
Status: | CLOSED ERRATA | QA Contact: | Entitlement Bugs <entitlement-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 6.3 | CC: | alikins, bkearney, ddumas, jmolet, jsefler, khong, syeghiay |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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 08:53:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 543577 | ||
Bug Blocks: | 771481, 840699 |
Description
Miroslav Suchý
2012-01-30 09:03:25 UTC
This is not a blocker, and we would like to deliver this by SNAP1. 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...? 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. 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. commit afd8acf6e38c25933152b6a5526882a860a289ba Author: Adrian Likins <alikins> 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 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. # 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. 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 |