Prior to its 7.2 version, IBM i had no concept of VLANs. They had to be managed externally. However, I am going to show you how to get IBM i to cooperate in a VLAN environment pre-v7.2. I am also going to demonstrate how simple it is to set up a v7.2 IP interface to use its new 802.1Q capability.
First, a bit of history. We’ve always had a requirement to split up our Ethernet networks and, prior to VLANs, we did this by having physically separate network switches. Most common was one network for the user traffic, a second network for management and a third for DMZ.
This, in turn, required that we had three LAN adapters in our system, one connected to each network.
To reduce the requirement for physically separate networks, a concept of VLAN-tagging was introduced. This allowed us to create virtual LANs within a switch infrastructure. It also allowed us to connect a single LAN adapter from our system to the switch and insert a VLAN ID into each packet. The switch could then route the traffic based upon the VLAN ID. If you see mention of IEEE 802.1q, then this is referring to this capability.
All the major operating systems have had this capability for a number of years with the notable exception of IBM i.
How have we managed? Prior to IBM i v7.2, we had to rely on either a physical or virtual Ethernet switch to determine the VLAN our IP interface was associated with.
If your system has physical adapters assigned to IBM i, then the physical switch port each NIC (network interface controller) is attached to will place the VLAN ID into each outbound packet. The switch will also strip out the VLAN ID from inbound packets. This is because IBM i wouldn’t understand the packet with a VLAN ID in it.
With an IBM i LPAR using virtual LAN adapters (VNIC), we are hardwired to the virtual switch built in to PowerVM on Power systems. When we create a VNIC in our LPAR profile, we can specify a default PVID. We can only specify a single value on each VNIC but this is where we assign the VLAN ID.
So, if we need an IP connection to a user VLAN, a management VLAN and a DMZ, we would have three VNICs assigned to our LPAR, each with the appropriate VLAN ID assigned by the network team.
Remember, IBM i has no idea what’s going on. Outbound packets have the VLAN ID inserted by PowerVM and inbound packets have the VLAN ID removed before hitting the OS.
Connecting to the core network
At this point, we only have our LPAR connected to the virtual switch within the system, not to the physical switch where our clients and other servers are connected to. In order to connect to the core network, we need to route our VNICs through VIOS which will have at least one physical LAN adapter connected to the core switch.
Both VIOS and the switch port(s) the LAN adapter(s) are connected to need to be configured to allow Ethernet traffic through on specific VLANs. In most environments, your network administrator will configure the access or trunk port(s) on the switch.
VIOS requires two devices. The first is a VNIC to enable it to communicate with the LPARs. When we create this VNIC, we enable the 802.1q capability so that the virtual switch allows multiple VLANs to flow through the VNIC and prevents the virtual switch from tampering with the VLAN IDs already encapsulated in the packets.
When we have a VIOS VNIC enabled for 802.1q, only the VLANs specified for that VNIC are allowed to flow through it. In many situations, I create two VIOS VNICs, one for production VLANs and the second for test/dev VLANs.
Whether you have one or more VIOS VNICs, you can then bridge these to the physical LAN adapter(s) assigned to the VIOS virtual server. This is called a Shared Ethernet Adapter (SEA) as it allows multiple VNICs to share the same physical adapter.
So here’s what we should have.
On our client LPAR profile VNIC:
■ Port Virtual Ethernet (VLAN ID) set to the value of the VLAN we’re connecting to.
On the VIOS LPAR profile VNIC:
■ 802.1q enabled and a list of the VLANs we’re allowing on this VNIC.
■ Shared Ethernet Settings enabled and a trunk port priority set.
On the VIOS:
■ A SEA configured with the VIOS VNICs mapped to it so that network traffic can pass through the VIOS to/from the LPARs.
■ A default VLAN ID to assign to any packets which are not tagged.
On the physical switch:
■ A trunk port configured specifying the VLANs that are to be allowed on this port.
■ A native VLAN port to assign to any packets that are not tagged.
What does v7.2 bring?
At 7.2, we have the capability to set the VLAN ID against the IP address(es). You will recall from previous releases that when we create an IP Interface (CFGTCP option 1 for most people) we need to specify a line description. V7.2 has a new sub-parameter as part of the line description, VLANID.
To keep our pre-7.2 capability, we would specify *NONE for the VLAN parameter. If we do wish to manage VLAN IDs from the OS, then we would specify the VLAN that the IP address is to use here. The main benefit of doing this is that we now need just one VNIC and, therefore, only one line description.
Glossary
Trunk port: A port on a physical switch that allows traffic for multiple VLANs is often referred to as a trunk port.
Access port: A port on a physical switch port that allows traffic for just one VLAN is called an access port.
VLAN tagging: A function of a physical or virtual switch whereby a VLAN ID is inserted into an Ethernet packet.
Default ID: In VIOS, this the VLAN ID to assign to an Ethernet packet that does not contain a VLAN tag. In Cisco-speak, this is called the native VLAN.
Native VLAN: In Cisco-speak, this the VLAN ID to assign to an Ethernet packet that does not contain a VLAN tag. In VIOS, this is called the default ID.
SEA: A VIOS device that maps one or more VIOS VNICs to a physical adapter allowing network traffic to flow in and out of the system to the LPARs. Note that the SEA does NOT require an IP address. It is used as a bridge between the physical network and the virtual network inside the Power System.
References
IBM Knowledge Centre: Add TCP/IP Interface V7R2
IBM Redbook: PowerVM Introduction and Configuration
Setting up SEA video by xmlisnotaprotocol on YouTube: Virtual Ethernet on VIO
Chapter from my series last year for PowerWire on the iProDeveloper archive (registration required): Getting to grips with VIOS, part 5: network virtualisation configuration
Glenn Robinson has been PowerWire‘s resident tech tipster for over a decade. He has worked in the IBM computing arena since 1986 on System/34/36/38 and AS/400 through to Power Systems today.
As systems architect for IBM systems and storage at RSI Consulting, based in Northampton, UK, he works predominantly with IBM i clients as well as those using AIX and Linux. In the last five years, he has also had a great deal if experience working with Power customers using SVC and V7000 storage virtualisation.