Alan, We are sharing OSA devices and I assumed OSA's would recognize another LPAR's IP address and not use the switch. But that was not the case, it was always sending to the switches. I saw that from the traces I was doing.
When did it "all of sudden" break. Well, that is hard to answer. The best we can tell was it last worked in June of 2023. The problem is this CPU is using shared DASD between all the LPAR's so FTP'ing between LPAR's is not normal. It was the MVS team that found the problem at the end of September. They have some software ordering process on one LPAR and this process will FTP to the other LPAR. The MVS team tried to run this process at the end of September 2023 and it started timing out. The MVS team member said the last time they used this ordering process was in June of 2023 and it worked. So, something happened between end of June and end of September to cause the problem. And no one knows what that was. I can ping the gateway IP with no problems. The routing tables just show two default routes to the two OSA connected switches. It also shows the /32 address for the VIPA and the two interface addresses. Since I can use the available defined CTC's, I will setup a configuration to bypass the switches. Thanks for your suggestions. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Alan Altmark Sent: Tuesday, October 3, 2023 6:34 AM To: [email protected] Subject: Re: SNA Link Replacement in Z/OS 2.5 On Tue, 3 Oct 2023 01:48:31 +0000, Hights, Charles <[email protected]> wrote: >I am trying to find a replacement for SNA Link in Z/OS 2.5. My problem, >I have >4 LPAR's on one physical CPU. Normally to IP between the LPAR's we >would just FTP to that LPAR's IP address and we had no issue. Now all >of sudden the traffic is timing out. My routes are very simple, just a >default route that sends everything to the switches that the OSA's >connect to. I have spoken to the Switch support team and they say since >the mainframes are on the same IP Segment it is not being passed to the >FW. Unfortunately the switch team doesn't have any tools that will show >what is happening to the traffic once the switch gets it. So I wanted >to bypass the switches and setup an SNA Link type replacement. I see >that feature is not defined in Z/OS 2.5. On another client we use Hiper >Sockets to bypass the switches for internal IP between the LPAR's. On >this particular CPU, Hiper Sockets devices are not configured in the IO >Gen. So is there something in Z/OS 2.5, besides Hiper Sockets, that support a >device and link type statements to all traffic between LPAR's on the same CPU? If your LPARs are in the same subnet *and* are sharing an OSA adapter, the OSA will "short circuit" the traffic between the LPARs and it will not be visible on the switch. Are you sharing OSAs? You say "All of sudden". What changed since the last time it worked? Are you able to ping the gateway IP? Your routing table should also show that the other LPARs are directly connected (not routed). You can also use the OSA Advanced Facilities on the HMC to verify that your LPARs' IP addresses are properly registered in the OSA. You should also be able to see byte counts in motion. You could reset the OSA, but that would affect outboard comms, assuming that's the same OSA that connects to the switch. >So I wanted to bypass the switches and setup an SNA Link type replacement. I >see that feature is not defined in Z/OS 2.5. On another client we use Hiper >Sockets to bypass the switches for internal IP between the LPAR's. On this >particular CPU, Hiper Sockets devices are not configured in the IO Gen. So is >there something in Z/OS 2.5, besides Hiper Sockets, that support a device and >link type statements to all traffic between LPAR's on the same CPU? No SNA links. You're already bypassing the switches by sharing OSAs. Remember that the OSAs are acting as a network offload processor for you, moving data from one LPAR to another for you. If you change to use HiperSockets, you will start to burn the Z CPU. If you have the headroom, no problem, but the more data you move, the more CPU you burn. Alan Altmark z/VM Development IBM ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
