Using Gateway will decided which physical path will be chosen to send
the data out on, but that does not mean that the IP address 30.10.1.71
will be used as the src IP address when the packet is sent out.  When
z/OS initiates the connection the src IP address will depend on if you
use SOURCEVIPA or not.

GATEWAY
    20.21.4.3   30.10.1.71 LG501
    20.21.5.5   30.10.2.20 LG502

HOME

   VIPA01       30.20.1.1
   LG501                30.10.1.71
   LG502                30.20.2.20

If you have SOURCEVIPA and z/OS initates a connection out to 20.21.4.3
it will use LG501, but it will use 30.20.1.1 as the src address.  If
z/OS initates a connection to 20.21.5.5 it will use LG502, but the src
address will still be 30.20.1.1.

If you do not use SOURCEVIPA, then when initiating a connection to
20.21.4.3 the source address will be 30.10.1.71 and initiating to
20.21.5.5 the source will be 30.10.2.20.

Now, when another host intiates a connection to z/OS, the z/OS IP
address will be whatever IP address the other host connects to, it does
not matter what interface z/OS sends the data out on or if you have
sourcevipa coded or not.



Hal Merritt wrote:

>> I'm still confused. The desire was to select a *link* or hardware path.
>> We do that in our GATEWAY statements. For example:
>>
>> GATEWAY
>>   ...
>>   20.21.4.3      30.10.1.71   LG501     8992       HOST
>>   ...
>>
>>
>> Packets for the target HOST with IP 20.21.4.3 will be routed via network
>> appliance 30.10.1.71 connected to hardware adapter LG501 with a MTU 0f
>> 8992 (gigabit).
>>
>> But a GATEWAY may not be appropriate in all situations. For the moment,
>> we are all static.
>>
>>
>> Ahhhhh.... Homer Simpson...... my hero.
>>
>>
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
>> Behalf Of John S. Giltner, Jr.
>> Sent: Saturday, October 22, 2005 9:00 PM
>> To: [email protected]
>> Subject: Re: Alternate home for zOS FTP Client ...?
>>
>> Sort of.  If you are using static VIPA and have SOURCEVIPA specified,
>> then the outbound source address will be the last VIPA address specified
>>
>> before a real interface.  Example:
>>
>>   OSA1 10.1.1.1
>>   OSA2 10.1.2.1
>>   VIPA1 10.100.1.1
>>   OSA3 10.1.3.1
>>   OSA4 10.1.4.1
>>   VIAP2 10.200.1.1
>>   OSA5  10.1.5.1
>>   OSA6  10.1.6.1
>>
>> Based on route statments the following source address will be used if
>>
>> route is via   source address used will be
>> OSA1           10.1.1.1
>> OSA2           10.1.2.1
>> OSA3           10.100.1.1
>> OSA4           10.100.1.1
>> OSA5           10.200.1.1
>> OSA6           10.200.1.1
>>
>> That I am aware of there is NO way to specify what the source address is
>>
>> for FTP client.  I wish there was, but if there is I can't find it.
>>
>>
>> Hal Merritt wrote:
>>
>
>>>>I'm confused. FTP uses whichever link that has a path for the target
>
>>
>> IP
>>
>
>>>>address.
>>>>
>>>>HOME addresses apply only to inbound traffic. In a static environment,
>>>>outbound traffic is routed according to GATEWAY or equivalent
>>>>statements. In a dynamic environment, the link used is the one that
>>>>connects to a router that knows how to reach the target address.
>>>>
>>>>HTH.
>>>>
>>>>-----Original Message-----
>>>>From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED]
>>>>Behalf Of Tom Sims
>>>>Sent: Thursday, October 20, 2005 12:13 PM
>>>>To: [email protected]
>>>>Subject: Alternate home for zOS FTP Client ...?
>>>>
>>>>(Crossposted here and to IBMTCP-L)
>>>>
>>>>One of our clients runs a single TCPIP stack with multiple HOME ip
>>>>addresses.
>>>>
>>>>Is there a way -- without a second stack and CINET -- to cause the zOS
>
>>
>>
>
>>>>FTP client to use a link other than the PRIMARYINTERFACE when opening
>
>>
>> an
>>
>
>>>>outbound session?
>>>>
>>>>Thanks in advance,
>>>>Tom Sims
>>>>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to