Just an FYI - lesson learned if anyone cares. I had planned to dynamically add the new interface in both the PROFILE dataset and in OMPROUTE. It turns out the order is very important, and I Assumed wrong. I did the Obey on the Profile first, which caused OSPF to learn partial info. It dynamically added the new IP address as a Generic vs OSPF interface. Then when I issued the correct F OMPROUTE,RECONFIG command, it cannot drop the Generic and relearn with the full OSPF definitions.
Solution per IBM: simply recycle OMPROUTE. And if it’s a quick down and back up, the managing routers should not drop anything. Unfortunately, no changes allowed this week; will wait for the weekend. Sent from [Proton Mail](https://proton.me/mail/home) for iOS On Mon, Aug 12, 2024 at 10:54 AM, roscoe5 <[[email protected]](mailto:On Mon, Aug 12, 2024 at 10:54 AM, roscoe5 <<a href=)> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
