|
Larry,
Once again, thanks for all your tips, etc.
All of our iSeries Virtual Ethernet, VLAN ids, etc, only affect LPAR to LPAR traffic and system maintenance that I do.
Our company has many other VLANs, all none iSeries.
None of our non-iSeries traffic is impacted by any of the iSeries VLANS, to the best of my knowledge.
I guess one day this could change, but not in the near future.
For the LPAR to LPAR traffic, yes, more host table entries, etc.
Mainly used by programmers for STRPASTHR, SAVRSTLIB, SAVRSTOBJ, SNDNETSPLF commands.
I'm not clear if the Service Tools LAN used for upgrades/installs and the Service Tools LAN for remote virtual optical have the same config, each LPAR would need at least one of these, correct.
My current host (DSLO images) are on my R&D partition with 10,000k drives, a bit slower.
My production partition has all SSD drives, so the installs/upgrades probably would go faster if I made it the host.
PTFs, I still order PTFs via SNDPTFORD from each partition, with a few partitions, I found this works. If I had many more LPARs, I probably would rethink this.
However, because I really only have 2 partitions, (production and test), the other two, upgrade and DSLO are for building DSLO images and testing upgrades, I thought of just copying the DSLO image to the production partition, less risk of error when I do the production V7R1 upgrade later this year.
Would like to know more about your "'scheme' to number my VLANs that is related to IP network"
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of DrFranken
Sent: Monday, January 06, 2014 9:36 PM
To: Midrange Systems Technical Discussion
Subject: Re: HMC Virtual Ethernet VLAN id management
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
www.frankeni.com
www.iDevCloud.com
www.iInTheCloud.com
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
psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
