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
