Isolating data connections

LPAR mode z/VM guest

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
This graphic is described in the preceding text.
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:
lszdev qeth 0.0.f5f0 --info --info
...
READONLY         ACTIVE
...
switch_attrs:    "802.1 [rr]"
Or, using sysfs to query the attribute directly:
cat /sys/devices/qeth/0.0.f5f0/switch_attrs
802.1 [rr]
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
This graphic is described in the preceding text.
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.

Examples

  • To check the current isolation policy: 
    # cat /sys/devices/qeth/0.0.f5f0/isolation
  • To set the isolation policy to ISOLATION_DROP: 
    # chzdev qeth 0.0.f5f0 isolation=drop
    Or, using sysfs:
    # echo drop > /sys/devices/qeth/0.0.f5f0/isolation
  • To set the isolation policy to ISOLATION_FORWARD: 
    # chzdev qeth 0.0.f5f0 isolation=forward
    Or, using sysfs:
    # echo forward > /sys/devices/qeth/0.0.f5f0/isolation

    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'.

  • To set the isolation policy to none: 
    # chzdev qeth 0.0.f5f0 isolation=none
    Or, using sysfs:
    # echo none > /sys/devices/qeth/0.0.f5f0/isolation
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.