My main problem was, I tried to use an OBEYFILE command to refresh OMPROUTE. I believe I should be using a MODIFY. F OMPROUTE,RECONFIG
I’m not yet 100% there, but past my original questions. Thanks for your help Sent from [Proton Mail](https://proton.me/mail/home) for iOS On Mon, Aug 12, 2024 at 10:14 AM, Wolfgang Fritz <[[email protected]](mailto:On Mon, Aug 12, 2024 at 10:14 AM, Wolfgang Fritz <<a href=)> wrote: > HI > > I use only one static Vipa / lpar > > but we have some dynamic VIPAS for each application (FTP, CICS, DB2 and > so on..) > > it works fine. > > regards > > Wolfgang > > Am 12.08.2024 um 15:51 schrieb roscoe5: >> Thanks again. >> I understand it’s a routing issue and I added a matching OSPF_Interface >> where the original one was defined, using the new IP and Destination Address. >> But when I issue the OBEYFILE command I get “EZZ7871I NO MATCHING INTERFACE >> STATEMENTS FOR 7.7.7.8 (VIPALINK2)”. >> My gut instinct keeps coming back to the PROFILE member where the >> original/working VIPA has the pair of physical IPAQENET interfaces with >> SOURCEVIPAINTs pointing at the VIPA. >> >> This new VIPA doesn’t have any matching physical interfaces pointing at it. >> >> I’m thinking I need a similar association, but multiple sources say that I >> don’t. >> >> No doubt I’m missing something simple. >> >> Just to be clear, the dynamic Obey of the PROFILE member does allow me to >> Ping the new IP from TSO, just not from the outside, confirming the OMP/OSPF >> issue. >> >> Sent from [Proton Mail](https://proton.me/mail/home) for iOS >> >> On Mon, Aug 12, 2024 at 8:19 AM, John S. Giltner, Jr. >> <[[email protected]](mailto:On Mon, Aug 12, >> 2024 at 8:19 AM, John S. Giltner, Jr. <<a href=)> wrote: >> >>> 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<[email protected]> 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. >>>> <[[email protected]](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<[email protected]> 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 >>>>>> <[[email protected]](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 >>>>>>> <[[email protected]](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<[email protected]> >>>>>>>>> Date: On Fri, Aug 2, 2024 at 6:39 PM >>>>>>>>> Subject: Fw: Multiple VIPAs >>>>>>>>> To:[email protected] <[email protected]> >>>>>>>>> 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 [email protected] with the message: INFO IBM-MAIN >>>>>> ---------------------------------------------------------------------- >>>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>>> send email [email protected] with the message: INFO IBM-MAIN >>>>> ---------------------------------------------------------------------- >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>>> send email [email protected] with the message: INFO IBM-MAIN >>>> ---------------------------------------------------------------------- >>>> For IBM-MAIN subscribe / signoff / archive access instructions, >>>> send email [email protected] with the message: INFO IBM-MAIN >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email [email protected] with the message: INFO IBM-MAIN >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
