Re: z/VM 5.2 conversion IP problem (solved)
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. Well, you do have a router address; it's just the other end of the link. The presence of broadcast depends on the type of media. Typically, P2P links have no all stations capability (in the comms world, P2P links are usually serial lines with only two ends), so there's no need for broadcast. And I assume the reason why Linux shows me a netmask of 255.255.255.255 for P2P connections is there is some code, No, there's only one host on the other end of the link, so you don't actually have a subnet on a P2P link. The key thing to remember about IP routing is that it's done on a hop-by-hop basis. The only thing an IP stack knows is that to get to a destination, you take x.y.z.q as the next hop along the way. Each node makes independent decisions, and subnet masks are just a way of saying that I can reach a group of a certain size via this next destination. The VM stack has always done subnet masks in a particularly arcane manner, but the basic rules are the same. 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. Earlier versions of the VM stack allowed defining links with the same IP address. 5.2 is finally enforcing the spec (as it should). In all fairness, Chuckie gave fair warning long ago that the official answer was that each link had to have a unique address and the short cut would stop working at some point. Now it has.
Re: z/VM 5.2 conversion IP problem (solved)
At the time, I sat down and wrote a sort of 'cookbook' approach to what I wanted, and how I got it, and David Boyes generously volunteered to set ut up as a pdf document on SNA's website. I'll be happy to provide similar service for this document as well. Anything that gives me an opportunity to use Bookie...8-) -- db
Re: z/VM 5.2 conversion IP problem (solved)
On Monday, 01/22/2007 at 07:59 EST, David Boyes [EMAIL PROTECTED] wrote: And I assume the reason why Linux shows me a netmask of 255.255.255.255 for P2P connections is there is some code, No, there's only one host on the other end of the link, so you don't actually have a subnet on a P2P link. In this I would agree, except to say watch out if you get into OSPF/RIP, because (according to our z/OS brethren) the OSPF protocol doesn't recognize non-subnetted networks and subnets are required (RFC 3021's 31-bit masks notwithstanding, I guess). It can be done, but you have to assign a subnet to contain all your dynamically routed p2p hosts. In this way, the host routes generated (you have to configure it to do that) will override the subnet route. But if something goes wrong, it goes WAY wrong. :-( This is why the OSPF configuration in z/VM 5.2 no longer allows a mask of 255.255.255.255. I'm not saying z/OS is necessarily correct, I'm just pointing it out to avoid further confusion. (Yeah, right. Sure.) Static routing is not affected as long it deals with hosts that are outside the scope of your dynamic routing protocols. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem (solved)
In this I would agree, except to say watch out if you get into OSPF/RIP, because (according to our z/OS brethren) the OSPF protocol doesn't recognize non-subnetted networks and subnets are required (RFC 3021's 31-bit masks notwithstanding, I guess). Hmph. Class D routes and non-subnetted networks are perfectly legal in OSPF; they're just not efficient use of routing table space and router resources compared to route summarization. Probably has more to do with implementations taking two or three times as much CPU if you permit large #s of discrete routes rather than summarizing them properly. This is why the OSPF configuration in z/VM 5.2 no longer allows a mask of 255.255.255.255. I'm not saying z/OS is necessarily correct, I'm just pointing it out to avoid further confusion. (Yeah, right. Sure.) Bug, IMHO. Valid route, should be valid syntax. The fact you *can* shoot yourself in the head is not the tool's problem. Your gun, your foot.
Re: z/VM 5.2 conversion IP problem (solved)
This is why the OSPF configuration in z/VM 5.2 no longer allows a mask of 255.255.255.255. I'm not saying z/OS is necessarily correct, I'm just pointing it out to avoid further confusion. (Yeah, right. Sure.) Bug, IMHO. Valid route, should be valid syntax. The fact you *can* shoot yourself in the head is not the tool's problem. Your gun, your foot. We're not talking about a route here. We're talking about the subnet mask on the interface configuration. Host routes are handled just fine. I agree, allowing customers to shoot them selves in various parts of their anatomy is *not* the tool's problem. However, it does become our problem when the shot is taken, they call us and their overall user experience is less than favorable. I think having the tool unload the gun is preferable. Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem (solved)
On Jan 22, 2007, at 12:00 PM, Miguel Delapaz wrote: I agree, allowing customers to shoot them selves in various parts of their anatomy is *not* the tool's problem. However, it does become our problem when the shot is taken, they call us and their overall user experience is less than favorable. I think having the tool unload the gun is preferable. Be careful with this road. Many presumably customer-friendly OSes assume that they are smarter than I am and know better than I do what I want to do. Most of the time, they are wrong. Fortunately, in *some* of them, the GUI is merely a shell over a good old Unix or Unixalike set of command-line utilities and a Unixish kernel, and I can *fix* the problem and get actual work done. In *others*, well, I click a bunch of buttons marked OK because there's only one button and NO. ABSOLUTELY NOT OK. HOWEVER, I ACCEPT THE HEINOUS SITUATION IN WHICH YOU HAVE LEFT ME, GRUDGINGLY, BECAUSE YOU LEAVE ME NO CHOICE IN THE MATTER probably would make for a funny-looking button. Adam
Re: z/VM 5.2 conversion IP problem (solved)
Bug, IMHO. Valid route, should be valid syntax. The fact you *can* shoot yourself in the head is not the tool's problem. Your gun, your foot. [snip] I agree, allowing customers to shoot them selves in various parts of their anatomy is *not* the tool's problem. However, it does become our problem when the shot is taken, they call us and their overall user experience is less than favorable. I think having the tool unload the gun is preferable. Ordinarily, I'd agree -- cranky people with broken networks make my day less fun too. On the other hand, there is a difference between blocking a technically valid configuration completely and a great big message warning you that you're about to do something the designers think is suboptimal but you let them do it anyway, trusting that they know what they are doing. There are legitimate reasons to allow this configuration, even if it's usually a bad idea (example: if you need to adjust weighting for a P2P link in a IGP that will eventually be redistributed into an EGP at some point, and you want to control where the aggregation happens, or force it not to happen at all). I think this situation merits the latter, not the former. You get to trade one set of less sophisticated cranky users for more sophisticated cranky network weenies with a mission to do odd things in their routing. I'm not sure that's an improvement...8-) -- db
Re: z/VM 5.2 conversion IP problem (solved)
Hi Shimon The SNA website (Sine Nomine Associates, not SNA/VTAM), might solve half the problem, that is how to distribute the document. But, SNA is more of a Linux oriented company. Yes, there also has some VM related stuff. But I don't think that a VM shop without Linux, would really come to or know about this site. The paper or whatever, is directly a VM related problem. The other host involved, might be Linux, VSE, z/OS, or another VM system. The SNA site might be a good start. Part of my question to all, is there a VM oriented site for documentation and other practices? VSE has one. Linux has many. VM has a download area for tools, but I don't see anything there for just documentation. And there are other sites that has presentations. I don't mind writting something about one idiots view/problem/solution, but in many aspects, I don't know what I'm talking about. I can talk about what a P2P connection looked like and reasons and whys there were coded a certain way, but I have not knowledge of the RFC (?) or the tangents off of the RFC that were taken to support mainframe channels back in the old days. But on the other side, I doubt that there are many system programmers that would have any knowledge or interest in the RFC world. As we wear so many hats (have different functions to do), that in many cases, all we want to know, is what we need to know. If there is sufficent interest, I don't mind writting something, based on what I have experienced. I do suspect that sufficient enought people on the VM listserv have followed this topic, that as others hit it and pose questions on the listserv, that they would be immediately directed to either the archives, to me, or to someone else that has been dumbed down to my level of understanding. When I mean dumb down, I mean: There are the IP gurus out there. They had the Cisco router training. They may be able to cite the RFC specs. And they may have loads of experience in large, well designed, IP networks. (In this case, I'm thinking of Alan Altmark.) I've met Alan at several conferences. Most of the times that he has been out to St. Louis, I've been there. Durning the email exchanges last week, I could see his face, as he smiles, turns his head sideways, then down as he realized I didn't get what he was trying to explain, and, as he tries to figure out how I took his message, and tries to dumb it down again to the next level. He was trying to come down to a common frame of reference. Eventually, we found that we were on two different syntax bases. My syntax base, only needed one IP address, no subnets, no host entries, no routers, no broadcasts, and it worked prior to z/VM 5.2. And because it was simple and worked, I boxed myself into a corner with a not well designed network. So a dumb down person is one that understands there was another way of coding P2P networks. It doesn't follow current RFC specs, if it ever did. As I've said in other posts, I've given the network types my TCPIP config file and they would just stare at it and question if it ever worked. Until z/VM 5.2, it always worked. G Then they would shake there head and leave, muttering something about mainframes. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/21/2007 10:19 AM On 19 Jan 2007 at 12:38, Tom Duerbusch wrote: 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. This reminds me of the problems I had getting multiple ESCON CTCs set up between systems and partitions. I got help here and got it to work, but I found the documentation unclear, to put it mildly. At the time, I sat down and wrote a sort of 'cookbook' approach to what I wanted, and how I got it, and David Boyes generously volunteered to set ut up as a pdf document on SNA's website. Maybe you could write up a similar kind of doc? Now that you know what you were looking for but didn't find, it should be easier to write it. What do you think? :-) Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 ** **
Re: z/VM 5.2 conversion IP problem (solved)
But, SNA is more of a Linux oriented company. Definitely *not* the case. That's just a small part of what we do. Part of my question to all, is there a VM oriented site for documentation and other practices? VSE has one. Linux has many. VM has a download area for tools, but I don't see anything there for just documentation. And there are other sites that has presentations. We're collecting a lot of that stuff by default. Send it over here, and we'll post it.
Re: z/VM 5.2 conversion IP problem (solved)
On 19 Jan 2007 at 12:38, Tom Duerbusch wrote: 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. This reminds me of the problems I had getting multiple ESCON CTCs set up between systems and partitions. I got help here and got it to work, but I found the documentation unclear, to put it mildly. At the time, I sat down and wrote a sort of 'cookbook' approach to what I wanted, and how I got it, and David Boyes generously volunteered to set ut up as a pdf document on SNA's website. Maybe you could write up a similar kind of doc? Now that you know what you were looking for but didn't find, it should be easier to write it. What do you think? :-) Shimon -- ** ** Shimon Lebowitzmailto:[EMAIL PROTECTED] VM System Programmer . Israel Police National HQ. http://www.poboxes.com/shimonpgp Jerusalem, Israel phone: +972 2 542-9877 fax: 542-9308 ** **
Re: z/VM 5.2 conversion IP problem (solved)
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 ofsomething. 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.0QDIO1 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 FirstHopFlgs PktSz Metric Link -- --- - -- -- Default HOST 205.235.227.41 UGHS 1500 none QDIO1 192.168.99.224 255.255.255.248 directUT 9216 none LLINUX27 192.168.99.227 HOST directUHS 9216 none LLINUX27 205.235.227.0 255.255.255.0directUT 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
Re: z/VM 5.2 conversion IP problem
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
Re: z/VM 5.2 conversion IP problem
I'm still having problems after last nights tests... Where Miguel says you don't have to have a HOST entry, when I leave it out, I don't get connected. When I put one in, I do get connected (but routing is still off). I'm now using the IUCV connection to a SLES9 31 bit with SP 1 machine that was working when we were under z/VM 5.1. For now, I'm setting the VSE/ESA 2.3 machines aside as it is all unsupported code and there might be some outstanding PTFs that now come into play. (Of course that could also be true with only SP 1 being applied on the Linux side.) So with the following HOME statements: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD 192.168.099.227 255.255.255.000 LLINUX27 ; 192.168.099.227 255.255.255.252 LLINUX27 ; 192.168.099.227 255.255.255.000 LLINUX27 ; 192.168.099.227 255.255.255.240 LLINUX27 Any one that has a mask specified, connects. When I ftp from DOS to Linux27, I get the VM banner. IFCONFIG shows the device is up. When I ftp from Linux27 to VM, IFCONFIG shows that it received packets, but shows 0 transmitted for that device. It seems to me that I can send packets to VM over the IUCV connection, but IP isn't routing them back out. On the GATEWAY side, I tried: GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - ; 205.235.227 255.255.255.0 = QDIO11500 ; 192.168.099.024 255.255.255.0 = LNEWESA4 1500 ; 192.168.099.000 255.255.255.240 = LY2KESA2 1500 192.168.099.227 HOST= LLINUX27 9216 ; 192.168.099.227 255.255.255.000 = LLINUX27 9216 ; 192.168.099.227 255.255.255.252 = LLINUX27 9216 ; 192.168.099.227 255.255.255.000 = LLINUX27 9216 ; 192.168.099.227 255.255.255.252 = LLINUX27 9216 ; 192.168.099.227 255.255.255.255 = LLINUX27 9216 ; 192.168.099.000 255.255.255.255 = LLINUX27 9216 ; 192.168.099.000 255.255.255.000 = LLINUX27 9216 ; 192.168.099.000 255.255.255.000 = LLINUX27 1500 ; 192.168.099.227 255.255.255.000 = LLINUX27 1500 First I commented out all other links. Just deal with one. For LLINUX27, the oldest statement is at the bottom. 1st tried the IP address. Then tried it as a subnet address. Then changed the MTU to match what IFCONFIG said from the Linux side. Nothing provided routing back to the Linux machine. I left it at the statement that is simular to what was used in the z/VM 5.1 side, which was: 192.168.099.227 = LLINUX27 1500 HOST Just in case, I'm attaching the entire configuration file. Perhaps I'm looking only at the HOST and GATEWAY statements, and I really have a problem somewhere else (between the ears). Thanks for any insight. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/16/2007 9:00 AM On Tuesday, 01/16/2007 at 08:22 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: OK, so I took out the statements in the HOME area. When I did that, VSE (via VCTCA, or the sole Linux image that is still using IUCV) wouldn't connect anymore. Sorry for not being clearer: - You must have a HOME entry for each interface - You may not duplicate any IP address in the HOME list. Each must be unique. - You should put each VM--VSE connection in its own .252 subnet. To the extent you are using host routes - You must have a HOST entry in the GATEWAY for each p2p peer. (Hmmm...Miguel: Do you still have to do that if you use a .252 subnet?) Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
I believe Alan brought this up yesterday, but I'll mention it again...the IP address on you VM system (in your HOME statement) *MUST* be different from the IP address on your linux system (i.e. the IP address on the HOST GATEWAY route): HOME 192.168.099.227 255.255.255.000 LLINUX27 GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 11:53 AM I believe Alan brought this up yesterday, but I'll mention it again...the IP address on you VM system (in your HOME statement) *MUST* be different from the IP address on your linux system (i.e. the IP address on the HOST GATEWAY route): HOME 192.168.099.227 255.255.255.000 LLINUX27 GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
You see the HOME statement. You see the 192.168.099.227 in the HOME statement. That must not be the same as the address of the Linux system. It is the same. I must be different. Two people have told you this. Maybe, if three do you will believe it. [EMAIL PROTECTED] wrote: It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 11:32 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: I'm still having problems after last nights tests... Where Miguel says you don't have to have a HOST entry, when I leave it out, I don't get connected. When I put one in, I do get connected (but routing is still off). I'm now using the IUCV connection to a SLES9 31 bit with SP 1 machine that was working when we were under z/VM 5.1. For now, I'm setting the VSE/ESA 2.3 machines aside as it is all unsupported code and there might be some outstanding PTFs that now come into play. (Of course that could also be true with only SP 1 being applied on the Linux side.) So with the following HOME statements: HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 HOST ; HOST PRODUCES: DTCPAR123I LINE 211: UNKNOWN LINK NAME IN HOME CMD You can't put HOST in the HOME statement. Just subnet masks. If you get errors in your PROFILE, it's hard to tell what worked and what didn't. You gotta have a clean startup. 192.168.099.227 255.255.255.000 LLINUX27 As I said previously, you put only VM IP addresses in the HOME list, not other hosts' IP addresses. What is VM's IP address w.r.t. LLINUX27? You MUST choose a unique IP address for the VM TCP/IP end of EVERY p2p connection, whether it's CTC or IUCV. You need to define a subnet that contains both VM and LLINUX27. This is why the choice of subnet mask 255.255.255.252 -- it defines a subnet with exactly two (and only two) hosts in it. Unfortunately, a /30 subnet can't have .227 as a host address because it's the broadcast address for the the .224/30 subnet (only .225 and .226 can be assigned). Now, if you broaden the mask to /29 (255.255.255.248), then you can have them both in the same subnet. GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 192.168.099.227 HOST= LLINUX27 9216 That entry looks good, AFTER you create a subnet mask that allows it and the matching HOME IP address to coexist in the same subnet. The presence of the HOST route will enable you to use that /29 to cover multiple p2p pairs. The .224 network will be located behind VM TCP/IP in all cases, but the host routes will tell the stack which interface to use. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Hi Ed, not a problem. I might be intelligent in some areas, but I'm hitting a brick wall with a dense head, here G. I wish I was hung over or something in order to have a valid excuse on this one. Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 1:17 PM Two people have told you this. Maybe, if three do you will believe it. Wow Stephen, are you having a bad day or what? Cut Tom some slack here. He is an intelligent guy who is having a problem. Just because YOU get what he needs to change doesn't mean he does. Haven't you ever had difficulty understanding something? I'm surprised you would be so negative, that doesn't seem like you. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: z/VM 5.2 conversion IP problem
Hi Stephen Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? It's really going to be a eureka moment, if and when I understand this. G Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/17/2007 12:42 PM You see the HOME statement. You see the 192.168.099.227 in the HOME statement. That must not be the same as the address of the Linux system. It is the same. I must be different. Two people have told you this. Maybe, if three do you will believe it. [EMAIL PROTECTED] wrote: It is different. But we might be talking about different things: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. So, I'm confused. What isn't different about them? Tom Duerbusch THD Consulting -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 1:58 PM, Tom Duerbusch wrote: I wish I was hung over or something in order to have a valid excuse on this one. Could be arranged. For tomorrow, anyway. Come on over. I'm expecting to knock off work about five today. Adam
Re: z/VM 5.2 conversion IP problem
I wish I was hung over or something in order to have a valid excuse on this one. Could be arranged. For tomorrow, anyway. Come on over. I'm expecting to knock off work about five today. Can I come too please? Maybe I can learn to tone down my reaction to listserv posts. Sorry I jumped all over you in public Stephen. That was intended to be a private email, but of course I sent it to the entire list. Ed Zell (309) 674-8255 x-107 [EMAIL PROTECTED] . CONFIDENTIAL NOTICE: This communication, including any attachments, is intended only for the use of the individual or entity to which it is addressed and contains information which may be confidential. If you are not the intended recipient, any distribution or copying of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately, delete the communication and destroy all copies. Thank you for your compliance.
Re: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 02:10 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? Just so you don't think you're going crazy, z/VM 5.2 tightened up the rules for the PROFILE. The rules have always been there, but the stack was forgiving and it worked in spite of itself. - HOME identifies all of *your* IP addresses. - GATEWAY HOST entries identify all of your p2p *peers* You know the old saying, One man's HOME is another man's HOST. Kinda like cross-coupling CTC pairs. OK, not really like it at all, but there is a ... symmetry ... in the configuration of p2p links. Your HOME address on the CTC or IUCV link will be configured as the peer IP address on the other host. Likewise, your HOST entry will be in the local interface configuration of the peer. As you've discovered in spades, getting those guests to a level that can use Guest LAN or VSWITCH is, like, a bazillion times better than hacking up (as you would a furball) a bunch of p2p configs. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Hi Allen I'm starting to see where you are coming from with this. Obviously, historically, there have been multiple ways of coding these entries. And I have been able to get away with my way for a couple decades (not bad, huh?) But it may be time to pay the piper on this one. It didn't last quite long enough. As within 18 months, the VM stack won't have any routing functions as everything would have (or should have been) converted to vswitch. Vswitch seems to be a much cleaner/easier solution. Good stuff. So, in the latest post towards Miguel: 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network b. Must be in the same subnet as the IP address for the host (Linux27) c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. e. The subnet address associates the IP address on the link with the IP address for the guest. 3. My GATEWAY statement seems to be correct On a tangent, vswitch. I am using sequential IP addresses for my Linux machines on the vswitch. And they are working, even under z/VM 5.2. Am I going to be facing future problems here. Would it be advisable to start using addresses on different .252 subnets? I do believe that vswitch is a switch and the VM stack was a router and they may be more dis-similar than similar. But in the areas where they are similar On a side note for those people that wrote the TCP/IP Planning and Customization manual. All the references and examples are big shop environments. Multiple real adapters (TR1, ETH1, FDDI1, SNA1, etc). Not really much for guest machines running under VM (CTCA, IUCV). True an adapter (real or virtual) is an adapter. And now the manual may be written more for real adapters as vswitch replaces CTCA and IUCV. Anyway, assuming the above interpretation of what you said is correct, it is time to dig thru the manual to see what I didn't read over and see what else I didn't read G. Thanks Tom Duerbusch THD Consulting
Re: z/VM 5.2 conversion IP problem
Perhaps now would be a good time for IBM to release a tutorial for the pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of migration from oldder network architectures to the new GuestLans/Vswitch architectures and then onto the VLAN stuff. Please remember that most of the VM audience now are NOT TCPIP GURUs. Explanations, pictures and lots of r eal examples will help pass your knowledge onto us. /Tom Kern On Wed, 17 Jan 2007 15:58:00 -0500, Alan Altmark wrote: ...snipped... Just so you don't think you're going crazy, z/VM 5.2 tightened up the rules for the PROFILE. The rules have always been there, but the stack was forgiving and it worked in spite of itself. - HOME identifies all of *your* IP addresses. - GATEWAY HOST entries identify all of your p2p *peers* You know the old saying, One man's HOME is another man's HOST. Kinda like cross-coupling CTC pairs. OK, not really like it at all, but there is a ... symmetry ... in the configuration of p2p links. Your HOME address on the CTC or IUCV link will be configured as the peer IP address on the other host. Likewise, your HOST entry will be in the loc al interface configuration of the peer. As you've discovered in spades, getting those guests to a level that can use Guest LAN or VSWITCH is, like, a bazillion times better than hacking up (as you would a furball) a bunch of p2p configs.
Re: z/VM 5.2 conversion IP problem
Quoting Tom Duerbusch [EMAIL PROTECTED]: Hi Stephen Since VM/ESA 370 mode, I don't think I ever had HOME statements for anything other than my VM system. That includes last week when we were on z/VM 5.1. Now, I think I'm being told that I need a HOME statement for each link statement. And now told that these few dozen HOME statements, all need IP addresses that don't duplication any of my HOSTs. So I'm really being dense here How, or what matches up the IP address in the HOME entry to the IP address used by the HOST? And if there is nothing that matches the two together, why have the entry in the HOST section to begin with? It's really going to be a eureka moment, if and when I understand this. G Tom Duerbusch THD Consulting I hope I can say it in a way that will look clearer. Assume a network that looks like this: linuxvmvse The VM is actually on two different nets, the one connecting it to linux, and the one connecting it to VSE. Inside VM's TCPIP it needs to know what is MY name for every network VM talks on. So in this case VM will need, in its HOME section, two different addresses. You said: The IP address of my VM system is 205.235.227.74. The IP address of the Linux system is 192.168.99.227. But actually, VM *must* have TWO IP addresses here, one on the 205.235.227. net and one on the 192.168.99. net. AFAIK, there ain't no way a host calling itself 192... will talk to another one calling itself 205... over one wire unless you have a router in between. so let's say VM is 205.235.227.74 *and* 192.168.99.240. HOME 205.235.227.74 VSENIC 192.168.099.240 LNXNIC (That HOME is not your adapter names, but I hope you understand the basic idea: one IP address for THIS computer - VM - on EACH network). Then we need to tell TCPIP where to find various outside systems. So, we tell it the IP address and mask of the network with the linux, and also the IP address/mask of the network with VSE. GATEWAY 205.235.227.120 255.255.255.0 = VSESYS 192.168.099.227 255.255.255.0 = LNXSYS (Making up a different IP for VSE). That way when it wants to communicate with VSE it knows what network adapter to use and how to identify itself, by finding the HOME line that meets the IP/mask criteria of VSE's network. Same for the linux... I probably didn't say this exactly according to Alan's definitions of things, but it is how I understand stuff. HTH, Shimon
Re: z/VM 5.2 conversion IP problem
Of course this throws things off even more as on the z/VM 5.1 system, I only had the single HOME entry (for 205.235.227.74) and I had (working correctly) about 3 dozen other interfaces. Attached is the old config file for z/VM 5.1. I agree that I may have gotten away with things that now, the newer code won't let me. And that may be a great part of my confusion. Looking at the config file, and the IFCONFIG output you've added, I see what you're trying to do. If this *exact* same configuration worked on z/VM 5.1, I'm not sure that we've *explicitly* changed anything to prevent it from working now. That's not to say we haven't made changes that cause it not to work because we very well may have. Note that you're really running (or trying to run) with an invalid configuration, and this is why it's important to have pictures of the network and a decent understanding of what all of the information on your network picture corresponds to. Below, I'll draw a basic diagram of what I understand your network to look like based on what you've told us and explain why your configuration doesn't make sense. -- | Linux | | Guest | -- o - Linux Guest's IUCV interface (IP address: 192.168.99.227) | | | | | o - VM System's IUCV interface (IP address: ???) -- | VM| | System | -- o - VM System's QDIO interface (IP address: 205.235.227.74) | | | | --- | Outside Network| --- So...based on this picture, 192.168.99.227 has no *real* direct connection to 205.235.227.74. It may be possible (depending on how strict the IP stack's implementation is) to trick this configuration into working. But relying on such a trick to continue working in the future is probably not a great idea. The only way to truly ensure connectivity is to assign an IP address to the VM System's IUCV interface(s). 1. Do I need a HOME statement for each interface? It seems that on z/VM 5.2, if I don't have one, I can't connect to the adjecent host. To really be a *valid* configuration, yes you do. 2. If I need a HOME statement for each interface, can the IP address for that interface be any unused IP address? One that is on the same class C network (such as 192.168.99.1xx for the 2xx hosts)? Or do I need to spread out the HOST addresses out so that a .252 subnet can address a unique network along with a single unique host (that is, instead of consequitive IP addresses for hosts, every 4th IP address)? It depends. If you're running a dynamic router (MPRoute) on VM, you're most likely going to have to resort to the .252 subnets (a good reason to think about ditching the point to point links and start implementing guest LANs). If you're not running a dynamic router, you can go with a less drastic trick and, like you said, use 192.168.99.1xx IP address on your VM system. If you do this, you should probably NOT put a subnet mask on the HOME statement for the IUCV links. Since they aren't really on the same subnet (physically), you don't want a subnet route for them. Simply add the appropriate HOST routes to your GATEWAY statement. 3. Then on the GATEWAY side. What I got use to (or got away with) on z/VM 5.1, was the first parm being the IP address of the HOST I was going to. The manual says that this isn't an IP address, but rather as subnet address. Getting those confused is part of my mistake. But it worked. Why? Is this a case of the code being tighten? However, as I now reread the manual, the first parm is the IP address of the host that is on the destination network and HOST is used to specify a host entry. So I would seem that my GATEWAY entry: 192.168.099.227 HOST= LLINUX27 9216 is correct. Yes, this is correct. If you read further in the description of the first operand the doc says: Alternatively, ipv4_dest can be specified as the IP address, in dotted-decimal form, of any host that is on the destination network. Which is really what applies in this case. Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
Tom, See the attached PDF diagram -- it might help you to understand the overall approach. All the white circles in the diagram need to have unique IP addresses, and the ones on the ends of the CTC/IUCV links need addresses in the same subnet. 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? All the interfaces defined ON THE VM STACK need a HOME interface.
Re: z/VM 5.2 conversion IP problem
My other post goes into more detail on the answers to these...but I'll reiterate here 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? Essentially, yes. 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network True b. Must be in the same subnet as the IP address for the host (Linux27) True c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. True if you're running a dynamic router...otherwise, not necessarily d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. True if you're running a dynamic router...otherwise, not necessarily e. The subnet address associates the IP address on the link with the IP address for the guest. True 3. My GATEWAY statement seems to be correct Yes Regards, Miguel Delapaz z/VM TCP/IP Development
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 2:58 PM, Tom Duerbusch wrote: So, in the latest post towards Miguel: 1. I do need a HOME statement for each interface, 30 some odd HOME statementsright? If you have VCTCs hanging off each of them, yes. 2. The IP statement on the HOME statement: a. Cannot duplicate any other IP address in the network True. b. Must be in the same subnet as the IP address for the host (Linux27) Well, presuming that Linux27 is only *one* of those links. And using host here is confusing. Anything with an IP stack is a host. The IP address of the VM side of the point-to-point link is in the same /30 subnet as the other side of the point-to-point link. c. Each link, will have its own subnet which contains the IP address of the link and the IP address of the host. Yes. Each netmask will be 255.255.255.252. In a /30 network (i.e., that netmask) there are four addresses. The bottom one is the network address. The top one is the broadcast address. That leaves two real addresses, one for each end of the link. d. I can't have sequential IP addresses (incremented by 1) for my Linux hosts. Not if they're on different CTCs, because that will violate subnetting. But if you have Linux hosts then why are you screwing around with VCTC at all? Just put them on a VSWITCH or Guest LAN segment and let them use (virtual) Ethernet adapters as God intended, and then you can have a nice roomy /24 (or whatever) subnet and not have to worry about it. Put them up against each other if you like. e. The subnet address associates the IP address on the link with the IP address for the guest. sort of. The VM and Other sides of the link have to be in the same /30 subnet. 3. My GATEWAY statement seems to be correct I didn't see anything wrong here. On a tangent, vswitch. I am using sequential IP addresses for my Linux machines on the vswitch. And they are working, even under z/VM 5.2. Am I going to be facing future problems here. Would it be advisable to start using addresses on different .252 subnets? I do believe that vswitch is a switch and the VM stack was a router and they may be more dis-similar than similar. But in the areas where they are similar No. Your Linux guests on a virtual LAN segment can have adjacent addresses and behave just like Linux machines on any other network anywhere in the real world. You want to get away from crazy subnetting by doing away with VCTC and IUCV connections in so far as possible. Adam
Re: z/VM 5.2 conversion IP problem
On Wednesday, 01/17/2007 at 03:11 CST, Thomas Kern [EMAIL PROTECTED] wrote: Perhaps now would be a good time for IBM to release a tutorial for the pre-5.2 - 5.2+ migrations. Lots of real-life examples and examples of migration from oldder network architectures to the new GuestLans/Vswitch architectures and then onto the VLAN stuff. Please remember that most of the VM audience now are NOT TCPIP GURUs. Explanations, pictures and lots of real examples will help pass your knowledge onto us. The VM sysprog is not expected to be an IP guru. S/he is, however, expected to consult with one when appropriate, as you have been doing here. (We just aren't getting our cut of your fee! :-) ) As I've said on many occasions, IBM manuals are, first and foremost, descriptions of how to configure or manage the product. They are not intended to be primers or treatises on the underlying technology. People go to school to become network engineers or architects. You or someone you have access to are expected to have an understanding of IP addressing and subnetting. Lack of knowledge can lead you down the Path of Darkness, where technicians-with-wirecutters reside and designers-with-attitude rule. It's easy once you know how! Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Where is this Wiki???
Re: z/VM 5.2 conversion IP problem
See the attached PDF diagram -- it might help you to understand the overall approach. All the white circles in the diagram need to have unique IP addresses, and the ones on the ends of the CTC/IUCV links need addresses in the same subnet. Blech. The attachment got stripped by the mailing list software. Find it here at: http://www.sinenomine.net/node/571
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote: Hi Adam That might be doable Thursday. I have an AA meeting tonight...just kidding. Got a favorite watering hole in mind? My living room was what I had in mind...I rarely go out to drink: see the first panel of http://www.fsf.net/~adam/Brown_and_White/ for why. But, failing that, maybe Schlafly Bottleworks in Maplewood? Or there's a bar on the bottom floor of the Dorchester on Skinker just south of Wash. U. that seemed like a pleasant, quiet, not totally smoky place. Amy can remember its name when she gets in. It has Thursday night fried chicken specials that are supposed to be excellent, although I went last week and found it pretty mediocre. Maybe it was an off week. Adam
Re: z/VM 5.2 conversion IP problem
On Jan 17, 2007, at 4:10 PM, Tom Duerbusch wrote: Hi Adam That might be doable Thursday. I have an AA meeting tonight...just kidding. Got a favorite watering hole in mind? John's Town Hall is the place I was thinking of with the fried chicken. Adam
Re: z/VM 5.2 conversion IP problem
You mean people actually get paid for this? To be more realistic, I have been able to configure two OSA driven VSWITCHes for separate inside/outside linux servers and to do cross-LPAR communications via a hipersocket, but it is still rather simplistic compared to a raft of point-to-point connections with lots of different subnets. 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. /Tom Kern --- Alan Altmark [EMAIL PROTECTED] wrote: The VM sysprog is not expected to be an IP guru. S/he is, however, expected to consult with one when appropriate, as you have been doing here. (We just aren't getting our cut of your fee! :-) ) As I've said on many occasions, IBM manuals are, first and foremost, descriptions of how to configure or manage the product. They are not intended to be primers or treatises on the underlying technology. People go to school to become network engineers or architects. You or someone you have access to are expected to have an understanding of IP addressing and subnetting. Lack of knowledge can lead you down the Path of Darkness, where technicians-with-wirecutters reside and designers-with-attitude rule. It's easy once you know how! Collections of real-world network pictures and their matching configs would be an excellent candidate for the Wiki. Alan Altmark z/VM Development IBM Endicott Don't get soaked. Take a quick peak at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
Re: z/VM 5.2 conversion IP problem
OK, so I took out the statements in the HOME area. When I did that, VSE (via VCTCA, or the sole Linux image that is still using IUCV) wouldn't connect anymore. On the VSE side (guest machine NEWESA4), I now get the following, no matter what other changes I make to the VM side: 0016: IPL380I Internet Link Level (ILL) Startup CTC Adapter, Cuu:0982 Link: LINK02 0016: IPL395E Senseid I/O error on receive port, Cuu:0982 Sns:41 LinkID: LINK02 0016: IPL391E Unable to Initialize CTC Adapter, Cuu:0982 Linkid: LINK02 Or, from the Linux side (SUSE9 31 bit SP1) guest machine LINUX27 ifconfig iucv0 Link encap:Serial Line IP inet addr:192.168.99.227 P-t-P:205.235.227.74 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:9216 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:30 dropped:30 overruns:0 carrier:30 collisions:0 txqueuelen:50 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) From VM, ifconfig -a shows: QDIO1inet addr: 205.235.227.74 mask: 255.255.255.0 UP BROADCAST MULTICAST MTU: 1500 vdev: 2110 type: QDIO ETHERNET portname: UNASSIGNED ipv4 router type: PRIMARY ipv6: DISABLED cpu: 0 forwarding: ENABLED RX bytes: 2388103 TX bytes: 38835113 LNEWESA4 inet addr: NONE mask: ? DOWN BROADCAST MULTICAST MTU: 9216 vdev: 0922 type: CTC portnumber: 0 connects to: NEWESA4 0983 cpu: 0 forwarding: ENABLED RX bytes: 0 TX bytes: 0 LLINUX27 inet addr: NONE mask: ? DOWN BROADCAST MULTICAST MTU: 9216 type: IUCV connects to: LINUX27 cpu: 0 forwarding: ENABLED RX bytes: 0 TX bytes: 0 My latest iteration of my VM IP setup (I spent a lot of time last night, playing with it): HOME 205.235.227.74 255.255.255.000 QDIO1 ; 192.168.099.227 255.255.255.240 LLINUX27 ; 192.168.099.024 255.255.255.240 LNEWESA4 ; 192.168.099.010 255.255.255.240 LY2KESA2 ; (End HOME Address information) ; -- ; -- ; Primary interface Definition ; -- PRIMARYINTERFACE QDIO1 ; -- GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - ; 205.235.227 255.255.255.0 = QDIO11500 192.168.099.024 255.255.255.240 = LNEWESA4 1500 192.168.099.000 255.255.255.240 = LY2KESA2 1500 192.168.099.227 255.255.255.240 = LLINUX27 1500 DEFAULTNET 205.235.227.41 QDIO11500 ; (End GATEWAY Static Routing information) I can't do much with it today, but I have time tonight to make changes. My current plans is to move the last remaining Linux image that is using IUCV to VSWITCH to bypass that problem. As
Re: z/VM 5.2 conversion IP problem
On Tuesday, 01/16/2007 at 08:22 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: OK, so I took out the statements in the HOME area. When I did that, VSE (via VCTCA, or the sole Linux image that is still using IUCV) wouldn't connect anymore. Sorry for not being clearer: - You must have a HOME entry for each interface - You may not duplicate any IP address in the HOME list. Each must be unique. - You should put each VM--VSE connection in its own .252 subnet. To the extent you are using host routes - You must have a HOST entry in the GATEWAY for each p2p peer. (Hmmm...Miguel: Do you still have to do that if you use a .252 subnet?) Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
On Jan 16, 2007, at 9:00 AM, Alan Altmark wrote: Sorry for not being clearer: - You must have a HOME entry for each interface - You may not duplicate any IP address in the HOME list. Each must be unique. - You should put each VM--VSE connection in its own .252 subnet. To the extent you are using host routes - You must have a HOST entry in the GATEWAY for each p2p peer. (Hmmm...Miguel: Do you still have to do that if you use a .252 subnet?) I'm not Miguel, but I always *have* done so. Sure, you could reason that there's only one other real address available in the subnet, so the gateway *must* be that one...and maybe the routing code does so. But it surely doesn't hurt anything to specify it. Adam
Re: z/VM 5.2 conversion IP problem
You don't *have* to have the HOST entry if you have the subnet route. It doesn't hurt, and will make some things more clear. For example, the P-t-P address on the IFCONFIG output is taken from the HOST routing entry. Regards, Miguel Delapaz z/VM TCP/IP Development The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on 01/16/2007 07:00:31 AM: On Tuesday, 01/16/2007 at 08:22 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: OK, so I took out the statements in the HOME area. When I did that, VSE (via VCTCA, or the sole Linux image that is still using IUCV) wouldn't connect anymore. Sorry for not being clearer: - You must have a HOME entry for each interface - You may not duplicate any IP address in the HOME list. Each must be unique. - You should put each VM--VSE connection in its own .252 subnet. To the extent you are using host routes - You must have a HOST entry in the GATEWAY for each p2p peer. (Hmmm...Miguel: Do you still have to do that if you use a .252 subnet?) Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
It has taken me a while to recall why I havn't been using more than 1 HOME statement. I did this many years ago and got the same result. When I update the configuration to: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 192.168.099.024 255.255.255.000 LNEWESA4 192.168.099.010 255.255.255.000 LY2KESA2 ; (End HOME Address information) Everything comes up. I can ping from VM to each of the IP addresses, fine, or so it seemed. I can also ping from the network to all the devices, fine, or so it seemed. But when I FTP from the network to one of the VSE addresses, it is the VM FTPSERVER that responds. Also, I can't ping from VSE up to VM or the LAN side. So with the old VM IP stack, I left out the home statements for the VSE networks. And we have run like this, on the MP3000 and later on the z/890. I do believe that the network folks have a hard route of the 192.168.99 network directed to/thru the 205.235.227.74 address. Perhaps that is what made the prior, not exactly perfect, config file work. So, I think I need a way to route the 192.168.99.24 traffic to the LNEWESA4 link. So I have: GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 205.235.227 255.255.255.0 = QDIO11500 192.168.099.24 HOST = LNEWESA4 1500 192.168.099.10 HOST = LY2KESA2 1500 192.168.099.227 HOST = LLINUX27 1500 DEFAULTNET 205.235.227.41 QDIO11500 And the ifconfig -a for this link shows: LNEWESA4 inet addr: 192.168.99.24 P-t-P: 192.168.99.24 mask: 255.255.255.255 UP BROADCAST MULTICAST POINTOPOINT MTU: 9216 vdev: 0922 type: CTC portnumber: 0 connects to: NEWESA4 0983 cpu: 0 forwarding: ENABLED RX bytes: 920 TX bytes: 0 That looked good. However, a FTP from DOS to VSE, ends up in VM: C:\ftp 192.168.99.24 Connected to 192.168.99.24. 220-FTPSERVE IBM VM Level 520 at STLMP11.STLOUISCITY.COM, 14:59:35 CST MOND 07-01-15 220 Connection will close if idle for more than 5 minutes. User (192.168.99.24:(none)): Am I correct, in the belief that this is a routing issue? Don't say that it is a network design issue. It grew on its own. OK I did water it a little. Thanks Tom Duerbusch THD Consulting [EMAIL PROTECTED] 1/14/2007 11:44 PM On Saturday, 01/13/2007 at 03:56 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an IP problem. Actually, I couldn't just take my ZVMV5R10 TCPIP statements and put them on the newer system. I had to rewrite many of them. Eh? Other than a nag message that your profile is in the old format, everything should have worked, subject to any tighter enforcement of general network design priniciples in the 5.2 stack. HOME 205.235.227.74 255.255.255.000 QDIO1 ; (End HOME Address information) With the VM startup, I got the same errors I've normally had. Of course, they may be more serious now. 15:03:21 DTCPAR123I LINE 231: NO IPV4 HOME ADDRESS FOR DEVICE NEWESA4 15:03:21 DTCPDO069I ADDBSDINFO: NO IPV4 HOME ADDRESS FOR LINK LNEWESA4 15:03:21 DTCPAR106I DEVICE:NEWESA4, TYPE:CTC 15:03:21 DTCPAR107ILINK: LNEWESA4, TYPE: CTC, NETWORK NUMBER: 0 15:03:21 DTCPDO076I192.168.99.24DIRECTLINK NAME: LNEWESA4 I infer from those messages and your PROFILE that you are missing the HOME address for NEWESA4. Make sure it is in the VSE subnet, not the OSA subnet. It is required that each link have a unique IP address. An ifconfig -a will likely show the device as down. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
On Monday, 01/15/2007 at 03:02 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: HOME 205.235.227.74 255.255.255.000 QDIO1 192.168.099.227 255.255.255.000 LLINUX27 192.168.099.024 255.255.255.000 LNEWESA4 192.168.099.010 255.255.255.000 LY2KESA2 ; (End HOME Address information) GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 205.235.227 255.255.255.0 = QDIO11500 192.168.099.24 HOST= LNEWESA4 1500 192.168.099.10 HOST= LY2KESA2 1500 192.168.099.227 HOST= LLINUX27 1500 DEFAULTNET 205.235.227.41 QDIO11500 R'uh r'ohthe IP addresses you have in the HOME statement are identical to those in your GATEWAY statement. NG. The entries in the HOME list are the IP addresses assigned to your *VM* system. Those in the GATEWAY are those assigned to the hosts on the other end of the CTCs. You also have overlapping subnets on the HOME statement. A point-to-point connection is more typically a .252 subnet. The overlap isn't fatal since you have HOST entries. Further, get rid of the GATEWAY entry for QDIO1 and put the MTU on the LINK statement. Draw a picture and you will see that you have 4 subnets; one to the OSA and one to each of 3 hosts. Your network config files should implement that configuration with 4 non-overlapping subnets with VM TCP/IP as the router. Alan Altmark z/VM Development IBM Endicott
Re: z/VM 5.2 conversion IP problem
On Saturday, 01/13/2007 at 03:56 CST, Tom Duerbusch [EMAIL PROTECTED] wrote: I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an IP problem. Actually, I couldn't just take my ZVMV5R10 TCPIP statements and put them on the newer system. I had to rewrite many of them. Eh? Other than a nag message that your profile is in the old format, everything should have worked, subject to any tighter enforcement of general network design priniciples in the 5.2 stack. HOME 205.235.227.74 255.255.255.000 QDIO1 ; (End HOME Address information) With the VM startup, I got the same errors I've normally had. Of course, they may be more serious now. 15:03:21 DTCPAR123I LINE 231: NO IPV4 HOME ADDRESS FOR DEVICE NEWESA4 15:03:21 DTCPDO069I ADDBSDINFO: NO IPV4 HOME ADDRESS FOR LINK LNEWESA4 15:03:21 DTCPAR106I DEVICE:NEWESA4, TYPE:CTC 15:03:21 DTCPAR107ILINK: LNEWESA4, TYPE: CTC, NETWORK NUMBER: 0 15:03:21 DTCPDO076I192.168.99.24DIRECTLINK NAME: LNEWESA4 I infer from those messages and your PROFILE that you are missing the HOME address for NEWESA4. Make sure it is in the VSE subnet, not the OSA subnet. It is required that each link have a unique IP address. An ifconfig -a will likely show the device as down. Alan Altmark z/VM Development IBM Endicott
