Well, imagine that, my test node (linux27) worked.
I guess things work right when you do it the legit way..
Who would have thunk?
So, now as I go back to try to correct my knowledge defect and get me on the
right path...
Historically, what I had (VCTCA and IUCV connections), was P2P. With P2P you
don't have a router address nor do you have a broadcast address. Just wasn't
needed. And I assume the reason why Linux shows me a netmask of
255.255.255.255 for P2P connections is there is some code, was in the z/VM 5.1
and earlier and in the Linux world, that handled P2P connections, slightly
differently. When we were on SLES 7 (well, still are for some of my machines),
there is a "netmask fix for Samba when using P2P communications".
So, starting with some release of z/VM, the TCP/IP code was updated to handle
P2P communications as a normal network connections. That is, a router address,
host addresses and a broadcast address. So now P2P connections would be
handled just like any other network fabric. (Am I getting warm?) Both ways of
coding was supported, but now the Linux side didn't have to make any changes to
support it.
And then with z/VM 5.2, and the major update to TCP/IP (must be a major update
in order to change the syntax of all the control cards), the "special" was of
handling P2P connections was dropped (or got broken). And the solution is to
get on board the legit way of specifying a P2P connection.
So, am I making sense (I know I'm glossing over a lot).
I've always wondered why the network guides and tutorials didn't seem to make
sense. Every time I questioned it, the network types (in person and online)
would say "P2P". I started with IP with the IBM 8332 LCS box. Now, all the
way up to OSA. Every time I've showed a network type, my configuration, they
would give a blank stare. I've always assumed it was the syntax looked
different. Now, looking at a series of P2P Linux images, each on a different
link and each with ascending IP addresses, incremented by 1, and did work,
would blow a network type, mind apart.
I'm not the first person to hit this, but I might be the last. But in case I'm
not the last, we need some type of....something.
I'm not thinking of something as formal as a manual, or even a Redbook.
Perhaps something a little more than the foils of some presentation. (Usually
a presentation doesn't happen at the right time, and the right time here is
prior to a conversion to z/VM 5.2.) And it has to be able to be accessible to
everyone "at need". We have sample code in the VM download area. But nothing
like a HOW-TO area for VM related topics.
In the TCP/IP Planning and Customization manual, there are very few examples on
VCTCA and IUCV P2P examples. Most of the examples are on real major stuff
(OSA, ETH1, SNA1, LAN1, etc). I think P2P connections are rather dead. More
used in historic configurations or obsolete systems. And I run a lot of
obsolete systems. And, this really only affects shops when they convert to
z/VM 5.2 or later. A one time deal. We don't need a lot of work for this one.
When I would do a NETSTAT HOME and only got my single OSA adapter link, I
didn't know that I was missing the links for my 3 dozen VCTCA and IUCV
adapters. (The following, I have only converted Linux27 at this point.)
IPv4 Home address entries:
Address Subnet Mask Link
------- ----------- ------
205.235.227.74 255.255.255.0 QDIO1
192.168.99.226 255.255.255.248 LLINUX27
NETSTAT GATE gave me a single line for each of my links. Apparently, I should
be getting two lines returned for each of my links.
Subnet Address Subnet Mask FirstHop Flgs PktSz Metric Link
-------------- ----------- -------- ---- ----- ------ ------
Default HOST 205.235.227.41 UGHS 1500 <none> QDIO1
192.168.99.224 255.255.255.248 <direct> UT 9216 <none> LLINUX27
192.168.99.227 HOST <direct> UHS 9216 <none> LLINUX27
205.235.227.0 255.255.255.0 <direct> UT 1500 <none> QDIO1
Of course, the documentation should show the old way of doing it. So types
like me, would identify that the way I was doing it, was the old way. And I
need to convert.
And then the problems of conversion. So far I found:
1. I can't have sequential IP addresses assigned to different links.
2. When I use a .252 for a subnet mask, some of my Host addresses end up being
either the router or the broadcast address. So their subnet mask needs to be
.248 or .240 or....
3. Ooops, some of the Linux images were converted to VSWITCH, using the same
IP address as they had when they were P2P. And they would have been taken out
of the TCP/IP configuration file. Can't have a newly defined subnet for the
P2P connection overlapping another address (such as on the VSWITCH).
4. This means that I can only have less then 64 P2P links on a class C
network. (a .252 netmask takes 4 ip addresses)
Perhaps when the network guys gave me a /22 supernet, they knew what they were
doing <G>.
I'm sure I'm going to hit other hurdles in this conversion.
I've looked at what systems I could retire. I have some "Linux litter".
I've looked at what systems I could convert to vswitch.
But no matter what, it seems like I still have systems that I have to change
the IP address.
I've thought about and rejected of having a string of P2P nodes (trying to keep
from changing IP addresses) such as:
192.168.99.220 *-P2P-->
192.168.99.221---P2P-->192.168.99.222--P2P-->192.168.99.223--P2P-->192.168.99.224--etc
There may be a reason why that wouldn't work in the first place, but I started
thinking about how fragile that network would be. Of course, I would put the
higher traffic hosts up the line. I also question the kind of response time I
would get from the last host. Most of these hosts have very little IP traffic
as most are idle. Still...
I've installed, upgraded, migrated some 30-40 VM systems in my life. Looking
at this IP mess I got myself into. I think it will take about 3-4 times longer
to straighten out then it takes to do a normal VM upgrade. Oh well, can't
teach old dogs....
Thanks for everyone's help
Tom Duerbusch
THD Consulting
>>> [EMAIL PROTECTED] 1/18/2007 7:52 AM >>>
On Wednesday, 01/17/2007 at 06:47 PST, Thomas Kern <[EMAIL PROTECTED]>
wrote:
> You mean people actually get paid for this?
You betcha! If you get yourself some Cisco router and switch education,
along with VM, VSE, MVS, and Linux network configuration expertise, you
have a marketable skill.
This is what happens when you let mainframers (who I typically define as
as sysprogs with no Classical IP Network training) start to manipulate
said networks! Their natural inquisitiveness and fascination with shiny
objects puts them squarely in harm's way. ;-)
The only problem is that they learn quickly which buttons give a shock and
which give a treat. Worse, they share that information with others in the
herd, thereby reducing the "opportunities" for people like me. (See how
upset I am? See?)
But if I could have charged for all those VM TCP/IP, Guest LAN, and
VSWITCH phone calls in the early days, I could have purchased that small
out-of-the-way island I've had my eye on for some time. (sigh)
> A basic picture with sample IP addresses on each end of a connection
followed
> by a corresponding configuration file explaining all of the required
fields
> would go a long way to solving these problems. So, I reiterate your (and
DB's)
> recommendation to post a network diagram when asking for help with a
> configuration problem.
Amen.
Alan Altmark
z/VM Development
IBM Endicott
