There is no simple answer here! Not that you are asking bad questions though.

Here's the thing it's all part of your NETWORK and should be managed as such. If you consider a heavily virtualized infrastructure such as our iDevCloud or iInTheCloud servers you will find at least 25 VLANs in use there the vast majority of which ARE connected outside of the Power Systems there. The point of that is if you just randomly pick numbers for your VLANs and later need to access them from outside the Power System you may find yourself (or your network guys) saying four letter words that were already taken when they named "Golf" :)

AND you've already opned the door here by saying "Bridge" which can carry VLAN IDs or not depending on how each end is configured. A single Bridge can transport a single or a while bunch of VLANs!

You suggest usage for some VLANs and I like some of them. First is the LPAR to LPAR communication LAN. I like it if you have significant traffic that must get between them. If the traffic is minimal then I recommend against it because it means extra configuration, likely host table entries, and if partitions are moved it's extra stuff to deal with.

Next you suggest SST LAN adapter, more appropriately "Service Tools LAN". I VERY much like having one VLAN for all of this. Pick a 'Host' partition and that one gets a typical IBM i Ethernet line and IP interface. ALL the rest of the partitions ONLY get a service tools interface on this VLAN. NO reason that I can think of not to have both PTFs and remote installs using this same VLAN and I certainly use just one for both functions myself. Usually this VLAN stays inside the Power System server but it COULD be bridged outside to reach other servers.

The Bridge is NOT a VLAN. It is a connection from inside to outside. YOU Need to decide if it's bridging just one VLAN or acting as a trunk and bridging multiples. Also this bridge can be an SEA in VIOS or configured through IBM i and the rules are different for each.

Personally I do NOT like the concept of matching VLAN IDs to the adapter number. I wouldn't rule it out completely though perhaps use adapter 9 and vlan 9 for the Service Tools LAN for example. Personally I use a 'scheme' to number my VLANs that is related to IP network not virtual adapter number but that's likely because I have so many of them.

Hope that gets you some food for thought.

- Larry "DrFranken" Bolhuis

On 1/6/2014 9:16 PM, Steinmetz, Paul wrote:

My Last 4 HMC/Virtual Ethernet issues were all due to VLAN id mismatches.
I'm looking for some good notes , tips for HMC VLAN id management.

First, confirming all the various uses for Virtual Ethernet, VLAN id, and which can / cannot be shared.
1)Virtual Line Descpitions for LPAR to LPAR comm (shared)
2)Virtual Line for Ethernet Bridge (shared)
3) SST LAN adapter for HMC network installs (not shared)
4) SST LAN adapter for remote virtual optical (not shared)
5) others?
Second, you cannot see the VLAN id from iSeries partition, so I'm thinking of making the VLAN id match the adapter id.
Do think IBM will ever add so you can see the VLAN id from i5/OS?
If this works, then if your displaying a CMN resource, adapter id equal VLAN id.
By default, virtual adapters 1 and 2 are usually serial.
Virtual Ethernet numbers usually will start at 3, 4, 5 etc.
So VLAN ID will be set to match the adapter number, 3,4,5,etc.

Third, I had a mismatch between the HMC profile VLAN id and the actual VLAN id, viewing through properties or DLPAR.
IPLing to fix the above did not correct the difference. Partition needed to be shutdown, activated via HMC.

Any thoughts from the group.

Thank You
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home


This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].