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 is the default.
drop
Specifies the ISOLATION_DROP policy. All packets from guests sharing
the same OSA adapter to the guest having this policy configured
are dropped automatically. The same holds for all packets sent
by the guest having this policy configured to guests on the same OSA
card. All packets to or from the isolated guest need to 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) needs to be isolated. Then Linux A declares its OSA adapter
(QDIO Data Connection to the OSA adapter) to be isolated. Any
packet being 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 could 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 Virtual Ethernet Port Aggregator (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 -a qeth 0.0.f5f0 --info --info
...
READONLY ACTIVE
...
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
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 using vNICs, VEPA mode needs to be enabled
on the respective VSWITCH. See z/VM®:
Connectivity, SC24-6267 for information
about setting up data connection isolation on a VSWITCH.
