Vic Cross wrote:
On Thu, 9 Sep 2004, ING. A. Neij wrote:
I wonder how to define VIPA correctly. After defining VIPA for the TCPIP guest I can reach/ping the z/VM LPAR at three IP addresses (see under for extract of profile tcpip).
Your profile looks okay, with one observation:
HOME 10.12.100.10 VIPA1 ; <-- SOURCEVIPA for ETH0 and ETH1 10.12.100.08 ETH0 10.12.100.09 ETH1 ; (End HOME Address information)
This obviously works for you, but might lead to problems due to ARP caching in your hosts and routers. VIPA addresses are normally allocated in a separate subnet from the physical network interfaces, so that the VIPA address itself is never directly associated with an ARP entry. That way if a network link fails, routing will take care of finding a new path to the destination and you don't have to worry about old entries in ARP caches.
When I take a look at the devices I can see OSA device 1500 is used but OSA device 1300 is not used???
I'm going to assume that you want traffic to be load-shared across the two ports... This will not happen automatically.
The route table in a TCP/IP host controls which interface is used for outgoing traffic. Basically, the IP stack will look for the most specific route that matches the destination of the packet to be transmitted. When the route table shows more than one entry for a given route (ETH0 and ETH1 in your case), even if that's the default route, it will simply use the one that's higher in the table -- in your case, it seems that is ETH0.
Remember that VIPA is first-and-foremost a redundancy enabler for higher availability. It does not address load sharing or balancing.
Where else do I have to define other/additional OSA devices e.g. to use them with VIPA?
If you're at z/VM 4.3 or higher, check out your TCP/IP manual for EQUALCOSTMULTIPATH in the ASSORTEDPARMS. This allows traffic to be balanced over equal cost routes (i.e. adding a little more smarts to the decision path I described above). This works for static routes as well as OSPF or RIP, but if you're using ROUTED for dynamic routing it will get turned off (so migrate to MPROUTE :).
These parameters provide load sharing for outbound traffic from z/VM to the network. Work with your networking people to ensure that they are supporting equal cost routing to provide load sharing of traffic inbound to z/VM. Use OSPF if you can for quickest recovery of a network path failure. You and the routers adjacent to z/VM must use the same routing protocol for this to work. Even if your network generally uses a different routing protocol (EIGRP for example), OSPF or RIP can be integrated on the network side to accommodate the z/VM requirements.
Note that this will only alter the behaviour of traffic that leaves your TCP/IP stack. It does not change how traffic is sent to you. If you stick with your current config you may end up with a fairly even distribution anyway (due to some randomness in the timing of ARP responses from your OSAs), but that's not to say that it's a reason to stay that way ;)
Cheers, hope this helps, Vic Cross
---------------------------------------------------------------------- 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
