There is no simple answer here! Not that you are asking bad questions
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)
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.
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071