Layer 2 transport mode: When would it be used?
If you have an environment with an abundance of Linux
images in a guest LAN environment, or you need to defi ne
router guests to provide the connection between these
guest LANs and the OSA-Express3 features, then using the
Layer 2 transport mode may be the solution. If you have
Internetwork Packet Exchange (IPX), NetBIOS, and SNA pro-
tocols, in addition to Internet Protocol Version 4 (IPv4) and
IPv6, use of Layer 2 could provide “protocol independence.”
The OSA-Express3 features have the capability to perform
like Layer 2 type devices, providing the capability of being
protocol- or Layer-3-independent (that is, not IP-only).
With
the Layer 2 interface, packet forwarding decisions
are based
upon Link Layer (Layer 2) information, instead
of Network
Layer (Layer 3) information. Each operating
system attached
to the Layer 2 interface uses its own MAC
address. This means the traffi c can be IPX, NetBIOS, SNA,
IPv4, or IPv6.
An OSA-Express3 feature can fi lter inbound datagrams by
Virtual Local Area Network identifi cation (VLAN ID, IEEE
802.1q), and/or the Ethernet destination MAC address. Fil-
tering can reduce the amount of inbound traffi c being pro-
cessed by the operating system, reducing CPU utilization.
Layer 2 transport mode is supported by z/VM and Linux on
System z.
OSA Layer 3 Virtual MAC for z/OS
To simplify the infrastructure and to facilitate load balanc-
ing when an LPAR is sharing the same OSA Media Access
Control (MAC) address with another LPAR, each operating
system instance can now have its own unique “logical” or
“virtual” MAC (VMAC) address. All IP addresses associ-
ated with a TCP/IP stack are accessible using their own
VMAC address, instead of sharing the MAC address of
an OSA port. This applies to Layer 3 mode and to an OSA
port shared among Logical Channel Subsystems.
This support is designed to:
• Improve IP workload balancing
• Dedicate a Layer 3 VMAC to a single TCP/IP stack
• Remove the dependency on Generic Routing Encapsu-
lation (GRE) tunnels
• Improve outbound routing
• Simplify confi guration setup
• Allow WebSphere Application Server content-based
routing to work with z/OS in an IPv6 network
• Allow z/OS to use a “standard” interface ID for IPv6
addresses
• Remove the need for PRIROUTER/SECROUTER function
in z/OS
OSA Layer 3 VMAC for z/OS is exclusive to System z, and
is applicable to OSA-Express3 and OSA-Express2 features
when confi gured as CHPID type OSD (QDIO).
31