In this context it does mean a connection does mean TCP connection. So once the connection is made the source/destination address will stay the same.
One thing I did forget to mention is that the IP address the FTP jobs use can't be associated with a specific OSA, so they need to use a VIPA/DVIPA address. Thinking about this a little more, you may need to do per packet. With FTP there are 2 TCP connections, one for command/control and one for the actual data transfers. If the FTP server you are sending to supports passive data transfers, then per-connection will work, but again depending on timing all 3 jobs could still go out over a single OSA. On Fri, 26 May 2023 16:00:41 -0500, Joel C. Ewing <jce.ebe...@cox.net> wrote: >I suspect "connection" in this context means the opening of a TCP/IP >socket, which establishes the path between ports on two nodes, and that >all subsequent packets follow that established path. That would >suggest that transmission of a single file by one FTP instance would >still be constrained to the bandwidth of a single interface. My >understanding of load balancing is that it distributes aggregate load >over multiple interfaces by spreading multiple transactions over >multiple paths rather than spreading multiple packets for the same >transaction over multiple paths--so alternate routes for packets of a >single FTP transaction wouldn't be an issue. > >If your object is to make two 1 Gbps interfaces behave as one 2-Gbps >interface for a single transaction, I believe that would be closer to >what is called Ethernet bonding of interfaces. I know Linux can support >this if you also have an Ethernet switch that can support bonding (and >that can support aggregate rates of 2Gbps). I don't know if that is >supported on z/OS. My understanding is that this can allow packets >associated with the same TCP/IP socket to follow different physical >paths, but the unit of transmission is still a packet. FTP transmitting >a large file supports multiple packets in flight before having to >receive a response back so it should be able to effectively utilize the >aggregate bandwidth by spreading those packets over multiple >interfaces. If FTP is in an interaction where a single packet is sent >and a response packet must be received before proceeding, you would >still be constrained by the bandwidth of a single interface because each >individual packet still travels over one physical interface. > > JC Ewing > >On 5/26/23 10:33, Steve Thompson wrote: >> I have a question about the alternating of packets. >> >> If one is using an MFT product with encryption and hand-shakes, will >> the alternating packets between routes not cause the "connection" and >> data xfer(s) to fail? >> >> I'm asking because I know just enough about Network traffic to be >> truly dangerous -- which means I know how to specify an IP address and >> port#, and not much more. >> >> Steve Thompson >> >> On 5/26/2023 11:25 AM, John S. Giltner, Jr. wrote: >>> z/OS can do load balancing if you have mutiple equal cost routes >>> defined, one route for each OSA and I think they could be the same >>> route, something like: >>> >>> BeginRoutes >>> >>> route default = OSA_INTERFACE1 >>> route default = OSA_INTERFACE2 >>> >>> ENDRoutes >>> >>> You could use either default, or code routes for specific >>> hosts/subnets. Using default will load balance all outbound traffic, >>> coding more specific routes will just load blance the traffic for >>> hosts matching those routes. >>> >>> You then add add one of the following statements to your IPCONFIG >>> statement. >>> >>> MULTIPATH PERCONNECTION >>> >>> MULTIPATH PERPACKET >>> >>> First one will have z/OS alternate which route it takes per TCP >>> connection. Connection request #1 get path/route #1, request #2 gets >>> path/route #2. Depending on timing all 3 jobs could still get sent >>> out the same OSA, but you will be using both OSA's so it won't impact >>> all traffic. >>> >>> Second one does the same thing, but per packet. More overhead but >>> both OSA's will be used "equally". >>> >>> No matter what you do, depending on your network setup either one of >>> these or, as Keith suggested, defining a ROUTE via a specific >>> Interface you could overload your network. If your whole >>> infrastructure is 1 Gbps Ethernet, your z/OS system can now push ~2 >>> Gbps through the network. >>> >>> >>> On Thu, 25 May 2023 19:37:10 +0100, Keith Gooding <kw...@yahoo.co.uk> >>> wrote: >>> >>>> Hi Rex >>>> >>>> Networking is not my speciality but you should be able to add a HOST >>>> route - see the BEGINROUTES statement in IP Config Reference. >>>> Something like this: >>>> >>>> ROUTE windows server IP address. HOST = OSA_INTERFACE2 >>>> >>>> where OSA_INTERFACE2 is the interface which you want to use. >>>> >>>> This example assumes that the server is on the same subnet as the >>>> adapter - change - to the router IP address if not. >>>> >>>> No guarantees. >>>> >>>> Keith Gooding >>>> >>>> Sent from my iPad >>>> >>>>> On 25 May 2023, at 16:41, Pommier, Rex <rpomm...@sfgmembers.com> >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I have a question about routing FTP traffic. First a bit about the >>>>> environment. Z14-zr1 with (2) 1-GbE OSA adapters shared across 3 >>>>> LPARs. The 2 adapters are not in a VIPA configuration. Right now >>>>> on this LPAR, only 1 of the adapters is defined to TCP/IP. I can >>>>> easily get the second OSA configured into TCP/IP on the LPAR so >>>>> that's not an issue. >>>>> >>>>> The situation/question. I have 3 jobs that run on the mainframe >>>>> that all 3 initiate an FTP process to Windows servers. Between the >>>>> 3 jobs they are pushing between 1.5 and 2 terabytes to the >>>>> servers. The jobs are currently single threaded and from looking >>>>> at the FTP output, they are pushing the Ethernet adapter that is in >>>>> use at 100%. My question is this: If I configure the second >>>>> adapter, is there a way that I can force one of these jobs to use >>>>> one of the OSA adapters and the other 2 to go to the second >>>>> adapter? From what I recall, z/OS doesn't do any kind of trunking >>>>> or load balancing so setting up a VIPA won't improve throughput by >>>>> using both adapters. I've meandered through the IP configuration >>>>> reference and see nothing that would give me this capability. >>>>> >>>>> TIA >>>>> >>>>> Rex >>>>> >>>>> ---------------------------------------------------------------------- >>>>> 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 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 > >-- >Joel C. Ewing > >---------------------------------------------------------------------- >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
