Configuring a network device as a member of a Linux bridge
You can define an OSA or HiperSockets device to be a
bridge port, which allows it to act as a member of a Linux®
software bridge. Use the bridge_role attribute of a network device in layer 2 to
make it receive all traffic with unknown destination MAC addresses.
Alternatively, use VNIC characteristics to configure a layer 2 network device to receive all unknown traffic.
Before you begin
To use the bridging support, you need OSA or HiperSockets hardware that supports layer 2 SETBRIDGEPORT functionality.
You can have one active bridge port per Internal Queued Direct Communication (IQD) or OSA channel. You can have either only secondary bridge ports, or one primary together with up to four secondary bridge ports per OSA or HiperSockets channel. If the primary, or currently active secondary, bridge port fails, one of the available secondary bridge ports takes over. For each secondary bridge port, set bridge_role to secondary.
If you configure your Linux instance to have a bridge port, consider other bridge ports that might be configured that share the channel. Bridge ports can be distributed, for example, over five LPARs with one bridge port each.
Devices for which VNIC characteristics are configured cannot also be configured as bridge ports.
On z13® and earlier mainframes: HiperSockets bridge ports only bridge traffic to and from HiperSockets ports in z/VM guests. On z14 and later HiperSockets bridge ports bridge traffic to and from all layer 2 HiperSockets ports that are not configured as
bridge_invisible
.
HiperSockets only: On IQDX channels
permission to configure ports as bridge ports must be granted in IBM®
zEnterprise® Unified Resource Manager (zManager). On machines in PR/SM mode, bridge ports can only be configured on IQD channels that are
defined as external-bridged
in the IOCDS. On machines in DPM mode, bridge ports can be
configured on any IQD channel.
About this task
The following sysfs attributes control the bridge port functions. The attributes can be found in the /sys/bus/ccwgroup/drivers/qeth/<device_bus_id> directory.
- bridge_role
- Read-write attribute that controls the role of the port. Valid values are:
- primary
- Assigns the port the primary bridge port role.
- secondary
- Assigns the port a secondary bridge port role.
- none
- Revokes existing bridge port roles and indicates that no role is assigned.
Assigning a role directly to a port prevents use of the bridge_reflect_promisc attribute.
- bridge_state
- Read-only attribute that shows the state of the port. Valid values are:
- active
- The port is assigned a bridge port role and is switched into active state by the adapter. The device receives frames that are addressed to unknown MAC addresses.
- standby
- The port is assigned a bridge port role, but is not currently switched into active state by the adapter. The device does not receive frames that are destined to unknown MAC addresses.
- inactive
- The port is not assigned a bridge port role.
- bridge_hostnotify
- HiperSockets only: Read-write attribute that controls the
sending of notifications for the port. When you enable notifications (even if notifications were
already enabled), udev events are emitted for all currently connected communication peers in quick
succession. After that, a udev event is emitted every time a communication peer is connected, or a
previously connected peer is disconnected. Any user space program that monitors these events must
repopulate its list of registered peers every time the status of the bridge port device changes to
enable notifications. Valid values are:
- 1
- The port is set to send notifications.
- 0
- Notifications are turned off.
Notifications about the change of the state of bridge ports, and (if enabled) about registration and deregistration of communication peers on the LAN are delivered as udev events. The events are described in the file Documentation/s390/qeth.txt in the Linux kernel source tree.
- bridge_reflect_promisc
- Read-write attribute that, when set, makes the bridge-port role of the port follow ("reflect")
the promiscuity flag (IFF_PROMISC) of the corresponding Linux network interface. You can specify the following values:
- none
- Setting and resetting the promiscuous mode on the network interface has no effect on the bridge-port role of the underlying port.
- primary
- Setting or resetting the promiscuous mode on the network interface that is served by this device causes the driver to attempt assigning (or resetting) the primary role to the port. If a port with the primary role exists, assignment fails.
- secondary
- Setting or resetting the promiscuous mode on the network interface that is served by this device causes the driver to attempt assigning (or resetting) the secondary role to the port.
Setting bridge_reflect_promisc to anything but none causes the bridge_role attribute to become read-only. The role of a port changes as a result of setting or unsetting the promiscuity flag (IFF_PROMISC) of the corresponding network interface. You can check the currently assigned role by reading the bridge_role attribute.
Procedure
Example
# chzdev -a 0.0.a007 bridge_role=primary # echo primary > /sys/bus/ccwgroup/drivers/qeth/0.0.a007/bridge_role
# cat /sys/bus/ccwgroup/drivers/qeth/0.0.a007/bridge_state
active