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) channel. You can have either only secondary bridge ports, or one primary and several secondary bridge ports.

Devices for which VNIC characteristics are configured cannot also be configured as bridge ports.

A HiperSockets bridge port requires that Linux runs as a z/VM guest.

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

To configure a network device as a bridge, issue a command of this form:
```
# echo <value> > /sys/bus/ccwgroup/drivers/qeth/<device_bus_id>/bridge_role
```
Setting the bridge_role attribute requires the bridge_reflect_promisc attribute to be none. Alternatively, to make the bridge-port role of the port follow the promiscuity flag (IFF_PROMISC) of the corresponding Linux network interface, issue a command of the following form:
```
# echo <value> > /sys/bus/ccwgroup/drivers/qeth/<device_bus_id>/bridge_reflect_promisc
```
where valid values are:
- primary
- secondary
- none
Check the state of the bridge port by reading the bridge_state attribute. Issue a command of this form:
```
# cat /sys/bus/ccwgroup/drivers/qeth/<device_bus_id>/bridge_state
```
where displayed values could be:
- active
- standby
- inactive

Example

In this example, a network device with bus ID 0.0.a007 is defined as a primary bridge port.

# echo primary > /sys/bus/ccwgroup/drivers/qeth/0.0.a007/bridge_role
# cat /sys/bus/ccwgroup/drivers/qeth/0.0.a007/bridge_state
active

What to do next

You can specify up to four secondary bridge ports together with one primary bridge port. If the primary bridge port fails, one of these bridge ports takes over. For each secondary bridge port, set bridge_role to secondary.