Red Hat Bugzilla – Bug 463177
[LTC 6.0 FEAT] 201686:Installer - HiperSockets MAC Layer Routing Support
Last modified: 2010-09-28 15:18:40 EDT
Emily J. Ratliff <email@example.com> - 2008-09-16 18:21 EDT
1. Feature Overview:
Feature Id: 
a. Name of Feature: Installer - HiperSockets MAC Layer Routing Support
b. Feature Description
HiperSockets support now also Layer2 modus (useful for applications depending on the existence of a
unique MAC address, like DHCP, tcpdump, channel bonding, HA...), so the installer should give the
possibility when configuring the network to be HiperSockets to:
- choose between Layer2 and Layer3
- if Layer2 to allow the user to set a predefined MAC address (optional), and if none is given, the
driver will generate one randomly.
Note: In previous releases there was a similar code path for OSA Layer2 support, which could be reused.
2. Feature Details:
Arch Specificity: Both
Affects Installer: Yes
Delivery Mechanism: Request Red Hat development assistance
Request Type: Installer - Enhancement from Distributor
d. Upstream Acceptance: No Code Required
Sponsor Priority 1
f. Severity: High
IBM Confidential: no
Code Contribution: no
g. Component Version Target: n/a
3. Business Case
These changes will improve the installation experience for customers by making the installation
workflow more usable and efficient (since the customer won't have to do the changes manually after
the installation), which will result on an improvement of the customer satisfaction. Without this
feature, the customer will be restricted to install only in Layer3 mode, and if Layer2 mode is
needed, will have to spend effort on doing the changes manually after the installation.
4. Primary contact at Red Hat:
5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, firstname.lastname@example.org, Boeblingen 49-7031-16-3978
Gonzalo Muelas Serrano, email@example.com
Thomas Schwarz, firstname.lastname@example.org
Exactly how is this implemented in the driver? What needs frobbed where to enable this on a running system?
Hello Red Hat,
to find out details about the implementation, I guess the best source will be the source code (the Layer2 functionality for HiperSockets is already upstream).
To enable Layer2 on HiperSockets, having the device offline, you have to:
echo <integer> > /sys/devices/qeth/<first_subchannel>/layer2
More info can be found under (recently updated):
Device Drivers, Features, and Commands - SC33-8411-01
We need IBM to provide the following:
1. Workflow inside anaconda that is impacted.
2a. Patches for anaconda to provide options or UI wire screens.
2b. Kickstart options to support the above.
------- Comment From email@example.com 2009-10-21 10:41 EDT-------
(In reply to comment #8)
> We need IBM to provide the following:
> 1. Workflow inside anaconda that is impacted.
Please check with David Cantrell and Brock Organ.
> 2a. Patches for anaconda to provide options or UI wire screens.
IBM is requiring Red Hat to enhance your RHEL intaller because IBM does not have the patches, sorry.
> 2b. Kickstart options to support the above.
Please check with David Cantrell and Brock Organ, but I think it could be "LAYER2"
Thank you for your support,
Gonzalo Muelas Serrano.
Fixing this bug requires patching linuxrc.s390 to ask if you want layer 2 or layer 3 if you choose the HiperSockets driver, then optionally prompting for a MAC address if you pick layer 2. If the user picks layer 2, the script needs to echo 1 to /sys/devices/qeth/<subchannel>/layer2
The network.py file may need patching to handle the layer 2 vs. layer 3 difference to ensure the MAC address is treated as optional when in layer 2 mode.
This bug may need to be cloned for NetworkManager to address the UI configuration elements in nm-connection-editor and possibly nm-system-settings.
IBM is signed up to test and provide feedback.
I'm hesitant to add a QA ack for this item until we have a testable reference implementation in fedora first ... can we start to identify, build and test the changes there?
(Then when that process is complete we can address the RHEL functionality with confidence that our specification will match the feature need ...)
------- Comment From firstname.lastname@example.org 2010-01-25 04:29 EDT-------
(In reply to comment #12)
> I'm hesitant to add a QA ack for this item until we have a testable reference
> implementation in fedora first ... can we start to identify, build and test the
> changes there?
> (Then when that process is complete we can address the RHEL functionality
> with confidence that our specification will match the feature need ...)
At this point in time, RHEL 6 on System z is the best "Fedora" on System z
we've got.... and RHEL 6 anaconda is being rebased from F13...
Without a working Fedora implementation we are unable to approve this for RHEL 6.0 inclusion. Closing as DEFERRED, resetting flags and moving to the RHEL 6.1 tracker for review for inclusion in that release.
------- Comment From email@example.com 2010-02-11 07:28 EDT-------
This feature is implemented in linuxrc.s390 by System z.
It has been discussed upstream last year and is upstream with Fedora12.
Feature tests passed once on alpha build RHEL6.0-20091130.0
Final feature tests planned on RHEL6 betas
Additional changes in e.g. nm-system-settings from Network Manager should not be required
The git commit:
layer2 option provided for all qeth device types:
Based on comment 12, moving to MODIFIED since this feature has been present since anaconda-12.38.5-1.
------- Comment From firstname.lastname@example.org 2010-06-15 01:42 EDT-------
This feature is verified on R6 snapshots
Set feature to "verified" Thx
Setting VERIFIED flag based on latest feedback.
Moving to VERIFIED based on comment 15.
Thank you for testing.
Red Hat Enterprise Linux Beta 2 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.