O.K., that is a routing issue. You need to look at your OSPF parameters and verify that you are setup to advertise 7.7.7.8 to your neighbors. If your not, then you need to update you OSPF parameters to advertise it and go from there. No matter what you may want to check with whomever handles your OSPF neighbors and see if they are setup to accept that route.
On Mon, 12 Aug 2024 11:49:22 +0000, roscoe5 <rosc...@protonmail.com> wrote: >John, >Thanks for your time and the thorough response. I’m not too concerned about >the applications, but your comments confirmed what I thought in that area. >One quick test failed to work in the OSPF space (did not recognize the new IP >address). However, I think I’ll have another test opportunity soon, so I’ll >continue down this path. >Thanks again! > >Sent from [Proton Mail](https://proton.me/mail/home) for iOS > >On Mon, Aug 12, 2024 at 7:40 AM, John S. Giltner, Jr. ><[000005a978a73af8-dmarc-requ...@listserv.ua.edu](mailto:On Mon, Aug 12, 2024 >at 7:40 AM, John S. Giltner, Jr. <<a href=)> wrote: > >> You should only ned to add a new VIPA: >> >> For all traffic that is initiated to your system, they just specify the >> destination IP address 7.7.7.8, or create a DNS entry that resolves to that >> address and have them use that host name. >> >> For most of traffic the that you initiate outbound I would look at using >> SRCIP entries with job names something like >> >> SRCIP >> >> JOBNAME MYTSTJOB 7.7.7.8 >> >> ENDSRCIP >> >> Then any job you submit with the name MYTSTJOB will use the address 7.7.7.8 >> as its source IP address. You can add multiple job names as needed or even >> code a pattern like MYTSTJ* and then any job that starts with MYTSTJ willuse >> 7.7.7.8 >> >> You can either update you existing TCPIP parameter and issue the OBEY >> command, or if you use PDS for your TCPIP parameters just create a new >> member with all of your SRCIP parameters and obey that member. >> >> To keep the SRCIP parameters across IPL's in your normal TCPIP parameters >> just INCLUDE the DSN of where you have coded the SRCIP statements. >> >> Once a TCP connection is setup between two IP addresses, all traffic will >> flow between those to addresses. So there is nothing that would cause a >> connection that was established with 7.7.7.8 to start flowing with 7.7.7.7. >> >> If you are still running standard FTP then you could have problems because >> it uses 2 TCP connections and it could be tough to have both connections use >> the new IP address. >> >> On Sun, 11 Aug 2024 20:50:24 +000 , roscoe5 <rosc...@protonmail.com> wrote: >> >>>I thought I had an answer, but no. >>>(Hard to test; can’t IPL) >>> >>>Trying to make this clearer. >>> >>>We currently have a single VIPA and two physical INTERFACE statements, let's >>>say ... >>> >>>INTERFACE VIPALINK1 DEFINE VIRTUAL IPADDR 7.7.7.7 >>> >>>INTERFACE LINK0010 >>> >>>DEFINE IPAQENET >>> >>>PORTNAME T0010 >>> >>>IPADDR 10.1.1.1/29 >>> >>>SOURCEVIPAINT VIPALINK1 >>> >>>... >>> >>>add >>> >>>NTTERFACE LINK0020 >>> >>>DEFINE IPAQENET >>> >>>PORTNAME T0020 >>> >>>IPADR 10.1.1.2/29 >>> >>>SOURCEVIPAINT VIPALINK1 >>> >>>... >>> >>>We woul like to add a second VIPA, VIPALINK2, very much like the first, >>>except with IPADDR 7.7.7.8. >>> >>>Do I need to create more IPAQENET INTERFACES (with or without new ports) and >>>give them a SOURCEVIPAINT VIPALINK2? >>> >>>Or is there any way to simply use the current existing IPAQENET INTERFACEs >>>and associate them with VIPALINK2? >>> >>>The obvious challengewwould be, how would the app/system know which VIPA to >>>use? Fair question. >>> >>>One of my peers suggested that as we expect the traffic would be inbound, it >>>would come in on 7.7.7.8. >>> >>>Further, any session created from inbound 7.7.7.8 shulld go back out on >>>7.7.7.8. >>> >>>Beyond the above technical question, some may want to ask why? What is tobe >>>gained. >>> >>>The answeris,multiple applications are using 7.7.7.7 with most unsecured. >>> >>>We intend to require ALL traffic on 7.7.7.8 be AT-TLS encrypted. >>> >>>Then test and migrate apps, independently, on to 7.7.7.8. >>> >>>Thanking in advance, >>> >>>Bob >>> >>>ennt from [Proton Mail](https://proton.me/mail/home) for iOS >>> >>>On Mon, Aug 5, 2024 at 5:22 PM, roscoe5 <[rosc...@prtoonmail.com](mailto:On >>>Mon, Aug 5, 2024 at 5:22 PM, roscoe5 <<a href=)> wrote: >>> >>>> Never mind, I figured it out. >>>> As is too often, I was making it more complicated than necessary. >>>> >>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>> >>>> On Fri, Aug 2, 2024 at 6:43 PM, roscoe5 >>>> <[0000056b62686b81-dmarc-requ...@listserv.ua.edu](mailto:On Fri, Aug 2, >>>> 2024 at 6:43 PM, roscoe5 <<a href=)> wrote: >>>> >>>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: roscoe5 <rosc...@protonmail.com> >>>>>> Date: On Fri, Aug 2, 2024 at 6:39 PM >>>>>> Subject: Fw: Multiple VIPAs >>>>>> To: ibm-m...@listserv.ua.edux <ibm-m...@listserv.ua.edux> >>>>>> Cc: >>>>>> >>>>>> Hello, >>>>>> In our TCP/IP (z/OS 3.1) we define OSA interfaces with IP addresses, and >>>>>> use the SourceVipaInt to refer to a Virtual IP address/interface. That >>>>>> much is working fine. >>>>>> I want to add another VIPA IP Address, where users can continue to use >>>>>> applications on (for example) 7.7.7.7 or get to the same services on the >>>>>> new 7.7.7.8 address. >>>>>> The plan is to use PAgent on the new address and enforce >>>>>> security/encryption. >>>>>> >>>>>> My question is, in the TCPIP Profile configuration, can I assign a >>>>>> native (not virtual) interface to two virtual interfaces (7.7.7.7 and >>>>>> 7.7.7.8)? Or do I need to duplicate the native interfaces with IPAQENET, >>>>>> PORTNAME, IPADDR, etc., and refer these new interfaces to the 7.7.7.8 >>>>>> virtual address? >>>>>> Thanks in advance, >>>>>> Bob >>>>>> >>>>>> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >>>>> >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >>> >>>---------------------------------------------------------------------- >>>For IBM-MAIN subscribe / signoff / archive access instructions, >>>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
