You can restrict communications between operating system instances that share an OSA port
on an OSA adapter.
About this task
A Linux® instance can configure the OSA adapter to
prevent any direct package exchange between itself and other operating system instances that share
an OSA adapter. This configuration ensures a higher degree of isolation than VLANs.
QDIO data connection isolation is configured as a policy. The policy is implemented as a sysfs
attribute called isolation. The attribute appears in sysfs regardless of whether the hardware
supports the feature. The policy can take the following values:
none
No isolation. This value is the default.
drop
Specifies the ISOLATION_DROP policy. All packets from guests that share
an OSA adapter to guests that have this policy configured are dropped automatically. The same holds
for all packets that are sent by the guest with this policy configured to guests on the same OSA
card. All packets to or from the isolated guest must have a target that is not hosted on the OSA
card. You can accomplish this by a router hosted on a separate machine or a separate OSA
adapter.
For example, assume that three Linux instances
share an OSA adapter, but only one instance (Linux A) must be
isolated. Then Linux A declares its OSA adapter (QDIO Data
Connection to the OSA adapter) to be isolated. Any packet sent to or from Linux A must pass at least the physical switch to which the shared OSA
adapter is connected. Linux A cannot communicate with other
instances that share the OSA adapter, here B or C. The two other instances can still communicate
directly through the OSA adapter without the external switch in the network path (see Figure 1).
Figure 1. Linux
instance A is isolated from instances B and C
forward
Specifies the ISOLATION_FORWARD policy.
All packets are passed through a switch. The
ISOLATION_FORWARD policy requires a network adapter in VEPA mode with an adjacent switch port
configured for reflective relay mode.
To check whether the
switch of the adapter is in reflective relay mode, read the sysfs attribute
switch_attrs. The attribute lists all supported forwarding modes, with the
currently active mode enclosed in square brackets. For
example:
The example indicates that the adapter supports both 802.1 forwarding mode and
reflective relay mode, and reflective relay mode is active.
Using a network adapter in VEPA mode achieves further isolation. VEPA mode forces traffic from the
Linux guests to be handled by the external switch. For example, Figure 2 shows instances A and B with ISOLATION_FORWARD specified
for the policy. All traffic between A and B goes through the external switch. The rule set of the
switch now determines which connections are possible. The graphic assumes that A can communicate
with B, but not with C.
Figure 2. Traffic from Linux instance A and B is forced through an external
switch If the ISOLATION_FORWARD policy was enforced successfully, but the switch
port later loses the reflective-relay capability, the device is set offline to prevent
damage.
You can configure the policy regardless of whether the device is online. If the device is online,
the policy is configured immediately. If the device is offline, the policy is configured when the
device comes online.
If the
switch is not capable of VEPA support, or VEPA support is not configured on the switch, then you
cannot set the isolation attribute value to 'forward' while the device is online. If the switch does
not support VEPA and you set the isolation value 'forward' while the device is offline, then the
device cannot be set online until the isolation value is set back to 'drop' or 'none'.
When you use vNICs, VEPA mode must be enabled on the respective VSWITCH.
See z/VM®:
Connectivity, SC24-6267 for information about setting up data
connection isolation on a VSWITCH.
