We’ve had a VIPA config so long I’m not sure we could remove it. We used to have active/active but with the implementation of ACI it broke it. They are looking at moving to something else so hopefully that occurs soon.
If z/OS Comm Server supported Link Aggregation it would be a moot point but alas it does not. Thanks for the response! On Thu, Jun 29, 2023 at 9:17 AM Pommier, Rex <[email protected]> wrote: > Michael, > > Are you planning on eventually going to a full VIPA configuration as > active/active? If not, consider just removing the VIPA configuration, > assign IP addresses to each card, start them both and point your client > community to one of the cards. That was the basic setup I had at a prior > site - with the intention of setting up a full VIPA but never got around to > it. I had some FTPs specifically going thru the second card so I know they > were both active. Somebody kicked a cable and my primary OSA port went > dark. The second OSA did an ARP takeover without the users even knowing it > had happened. We happened to see the ARP takeover messages on the console > is how we initially knew it had occurred. Once the cable was > repaired/reinstalled the primary card did an ARP takeover automatically so > everything was back to original state. I had to do nothing for the > failover or failback. > > Needless to say I was pleasantly surprised. > > Rex > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Michael Babcock > Sent: Thursday, June 29, 2023 8:37 AM > To: [email protected] > Subject: [EXTERNAL] Question for the List regarding OSA cards > > Hopefully there are some network gurus on IBM-MAIN. > > We have an LPAR that has two OSA Express6 cards (latest cards with a > z15) defined. Both interfaces are defined in the TCPIP Profile data > set. We also have a VIPA address defined. The PRIMARYINTERFACE is set to > the VIPA address. The START for one of the cards is commented out. As > such, the LPAR uses the card that was started at IPL time and the other one > is inactive (CARD1 is active, CARD2 is inactive since there is no START for > it). All traffic goes through the single OSA at this point. The IPCONFIG > statement has NOMULTIPATH. > > We want to get to an ACTIVE/STANDBY configuration such that both cards are > STARTED but all inbound and outbound traffic goes through CARD1 and > CARD2 is doing nothing (so if CARD1 fails, CARD2 takes over). We also > use CISCO's ACI so we experience the "flapping" issue with both cards > ACTIVE/ACTIVE and MULTIPATH active (hopefully ACI is going away soon). > > If we start the second card, we see traffic going through both cards > (which causes ACI a little heartburn). > > How do we achieve our goal? Keep in mind I'm not a network guy. > > Here's some of the config statements in the TCPIP profile if that helps. > > IPCONFIG > SEGMENTATIONOFFLOAD CHECKSUMOFFLOAD > QDIOACCELERATOR QDIOPRIORITY 1 > PATHMTUDISCOVERY > IGNOREREDIRECT > NODATAGRAMFWD > NOMULTIPATH > SOURCEVIPA > SYSPLEXROUTING > DYNAMICXCF ZZZ.ZZZ.ZZZ.ZZZ 255.255.255.0 1 > > INTERFACE LINK0506 > DEFINE IPAQENET > PORTNAME DEV0500 > INBPERF DYNAMIC WORKLOADQ > IPADDR XX.XXX.XXX.XXX/24 > VLANID 108 > VMAC ROUTEALL > MTU 1492 > SOURCEVIPAINT VIPAL06 > > INTERFACE LINK0906 > DEFINE IPAQENET > PORTNAME DEV0900 > INBPERF DYNAMIC WORKLOADQ > IPADDR XX.XXX.XXX.YYY/24 > VLANID 108 > VMAC ROUTEALL > MTU 1492 > SOURCEVIPAINT VIPAL06 > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > The information contained in this message is confidential, protected from > disclosure and may be legally privileged. If the reader of this message is > not the intended recipient or an employee or agent responsible for > delivering this message to the intended recipient, you are hereby notified > that any disclosure, distribution, copying, or any action taken or action > omitted in reliance on it, is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify us immediately > by replying to this message and destroy the material in its entirety, > whether in electronic or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
