I appreciate all your help and patience. There was/is still confusion on
my part. I thought that since I did not have the CTC from z/OS as part of
the OSPF routing and VIPA configuration that it would not contain the
source VIPA in the packet. I then figured that the source would be the
z/OS CTC. Since there was a static route to Linux from z/OS, the packet
should have no problem getting there. On Linux, there was another static
route to get it back. As you pointed out, I was wrong. Please bear with me
here though. I displayed my routes under Linux, and sure enough the z/OS
LPARs VIPA was learned correctly. See below.
O>* 161.186.98.0/24 [110/11] via 10.28.91.20, eth1, 02:32:51
via 10.28.93.20, eth0, 02:32:51
O 161.186.98.20/32 [110/11] via 10.28.91.20, eth1, 02:32:51
via 10.28.93.20, eth0, 02:32:51
The VIPA is being learned from the 2 OSA/e interfaces under z/OS as I
expected. However, these routes were not helping me. I had to insert the
following static to force the VIPA over the CTC instead of the OSA/e
interfaces. This is where my confusion begins again. If the interface a
ping request comes in on has no bearing on the interface chosen to return
the ping response, why was this static necessary? It looks like the packet
had a source VIPA of 161.186.98.20 but was hanging up in the network
somewhere.
S>* 161.186.98.20/32 [1/0] is directly connected, ctc0
I was hoping to reserve the CTC for high volume DB2 data and use the OSA/e
for normal network activity.
As far as Quagga, I will look at it this weekend. I am new to Linux and do
not fully understand how to install source RPMs yet.
Peter
Alan Altmark <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
03/26/2004 02:38 PM
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject: Re: CTC Route Problem
On Friday, 03/26/2004 at 01:44 EST, "Peter E. Abresch Jr. - at Pepco"
<[EMAIL PROTECTED]> wrote:
> If I use the default route, I can ping. The default does not address the
> 2nd CTC from another z/OS LPAR. If also causes problems with users
coming
> from the OSA connections.
>
> My goal is to run VIPA on Linux using Zebra and OSPFD. This allows the
> Linux system to learn the default route. Of course this does not help us
> if the ping is not going back to the way it came.
>
> I should not need the default route. Linux knows about network
> 161.186.86.4/30 or as it stands now, 161.186.86.5/32. Why is Linux not
> sending the packet back via this network route? Why is it not going back
> the way it came? I am so confused. Maybe it is time for a beer :)
As I said before, those packets do not contain 161.186.86.5 as the origin
IP address. They contain the associated z/OS VIPA address (because you
have SOURCEVIPA active on z/OS).
Route selection is based entirely on the routing table. There is no
magic; if the Linux routing table does have an entry for your VIPA subnet
or host, or a default route, pointing Linux in the right direction, the
packet goes nowhere.
The interface a ping request comes in on has no bearing on the interface
chosen to return the ping response.
BTW, I suggest looking at Quagga. Zebra and OSPFD are dead. And if you
aren't actively running a routing daemon, you most certainly do need a
default gateway spec. Don't worry - when you start up the routing daemon,
it will override whatever you put in there.
Alan Altmark
Sr. Software Engineer
IBM z/VM Development
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
