On Friday, 03/26/2004 at 06:24 EST, "Peter E. Abresch Jr. - at Pepco" <[EMAIL PROTECTED]> wrote: > I appreciate all your help and patience. There was/is still confusion on > my part.
If it was easy, everyone could do it and the world wouldn't need me any more. (It kind of brings a tear to your eye, doesn't it?) > 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. Tricksy, it is. > 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 Without dynamic routing, there is no "learning". There are implicit routes based on the IP address and subnet mask. That's it. Anything beyond that must be explicitly coded by you. Remember, too, that VIPA is based on the illusion of routing. To Linux, a VIPA subnet or host is not directly attached (more easily seen on a network diagram). That means a routing entry is required. And you still want a default route defined. > I was hoping to reserve the CTC for high volume DB2 data and use the OSA/e > for normal network activity. A perfectly reasonable thing to do, though you might want to consider HiperSockets instead. Remember that the CTC is stuck at channel speed limits, no matter how fast the network or server. HiperSockets and OSA (QDIO) move data at CPU speed instead of channel speed. The faster the CPU, the faster the data movement. 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
