I am facing some of the same issues.
I have hipersockets and OSA with four zLinux LPAR's and four zOS LPAR's in
one box (z890). We connect to a CISCO router that takes us to the rest of
the network including proxy and firewall servers.
We are using VIPA (to a dummy interface) and quagga/zebra/ospf to
adevertise the IP address of the VIPA (dummy interface). I noticed that
the /etc/hosts gets build on my behalf so resolutions take place within the
box without having to go to the DNS when communication is required between
LPAR's. However, I don't see the hipersocket address for this
configuration so I assumed that I had to do separately.
OSPF is building its dynamic routing and it knows about the multiple routes
(ip route) to each of theLPAR's plus the rest of our network. This is a
great feature for anybody accessing any of the LPAR's from outside the box.
However, when traffic leaves the LPAR, the return (source) IP address gets
labeled with the IP address of the interface. This is bad news.
Source-VIPA fixes this problem but it seems cumbersome to use. IPTABLES
can also fix it and I am dealing with that approach right now (ip route is
also supposed to fix it but I still don't know how to issue the proper
command).
Please keep us posted and to how hipersockets can be used without having to
have each application specify the exact IP address of the hipersocket and
without having to go to a DNS server. I am going to explore the /etc/hosts
approach, it seems clean.
Regards,
[EMAIL PROTECTED]
NCCI
Boca Raton, Florida
561.893.2415
greetings / avec mes meilleures salutations / Cordialmente
mit freundlichen Grüßen / Med vänlig hälsning
Vic Cross
<[EMAIL PROTECTED] To:
[email protected]
au> cc:
Sent by: Linux on Subject: Re: Hipersockets and
VLANs
390 Port
<[EMAIL PROTECTED]
IST.EDU>
06/30/2005 11:53
AM
Please respond to
Linux on 390 Port
On Tue, Jun 28, 2005 at 04:48:17PM -0400, David Kreuter wrote:
>
> Is this possible:
> 10.1.1.x host in Real Switch; Real Switch turnk port via OSA to Vswitch
> in LPAR A with linux host 10.1.1.19; same linux host has a hipersocket on
> 1.2.3.4 with VLAN enabled connecting to a linux host in LPAR B at 1.2.3.5
> with VLAN enabled. Linux host on LPAR A with VLAN enabled configures
> 10.1.1.29; linux host on LPAR B with VLAN enabled configures 10.1.1.39.
> So now a packet can journey from 10.1.1.39 to real host 10.1.1.19 over
> hipersocket over LPARa's OSA??
I read this wrong first up. I'm pretty sure now that you just want to get
from A to B via the Hipersockets rather than the OSAs. That's not too
difficult actually; it's a SMONR[1], and after that a SMOR[2]. :)
Whenever you're dealing with multi-homed hosts, you have the problem of
getting the kernel to choose the right interface for the job (this is a
problem not unique to Linux, or mainframes). You know Linux on LPAR A
by 10.1.1.19; from Linux on LPAR B, if you use that address you go over the
OSA -- not what you prefer. You need to use 1.2.3.4 as a destination, but
that's not the address that's stored in DNS for Linux on LPAR A.
Your proposal of trying to get the Hipersockets to look like part of the
LAN is fraught with danger. Don't look at doing that. You would need to
look at the Linux Ethernet bridging code, and quite apart from whether it
is actually possible to bridge an Ethernet to a Hipersockets, there is
massive
potential to cause real problems on the LAN environment.
The better approach is just to use the right destination IP address. The
easiest way to do that would be to add each of the Linux guests to each
others
/etc/hosts file, using the Hipersockets IP address. If you've got a number
of hosts attached to the Hipersockets though, this might get messy; a
different approach would be to define a second hostname in DNS for each
system.
Clients on the LAN say "ssh lparA-linux", you (from Linux on LPAR B) say
"ssh
lparA-linux-hipers" (for example).
For the really adventurous, you could set up your own DNS in the mainframe
Linux environment. That way you could have your own IP address mappings.
This only works well if your Linux systems are in their own DNS zone
(because
you don't want to have to keep your own copy of everything else in the same
DNS zone). There are other DNS tricks that can be done though; BIND 9 has
ways to provide different information depending on where the request came
from, which would be a creative way of addressing the issue.
VIPA can help the name resolution problem too. By using a virtual address
as a destination, the best way to reach that address from any given host is
determined by routing. This works best when a dynamic routing protocol is
used, so that everyone learns the best path to the virtual address from
wherever they are. Unfortunately the amount of cycles that our typical
routing daemons consume makes them an unattractive proposition for large
installations.
> I know as an alternate I can do this by connecting both using a shared
OSA
> port on LPAR A and LPAR B - but - I need all the justification I can
muster
> for a hipersocket solution -
A shared OSA certainly would relieve you of the multihoming issues that
using
a Hipersockets creates. It obviously doesn't give you all of the
Hipersockets
goodness though, and the issues of multihoming really are not so
significant
that you should have to give up on using Hipersockets.
> Don't ask - network planner at client site does not want to introduce
"new
> subnets or networks" - vswitching into z/VM LPARS is fine -
Then just be vewwy vewwy qwiet... :) You could use an arbitrary IP subnet
(like an RFC1918 private range -- if your company is using 10/8, then pick
something from 172.16/12 or 192.168/16) and don't try and advertise it or
use
it as a backup routing path or anything else. The systems attached to the
Hipersockets will be the only systems that ever need to know about it.
Of course I'd never *really* advocate doing such a thing, but it could be a
way to get an official network from the planners quick-smart ;)
Cheers,
Vic Cross
[1] Simple Matter Of Name Resolution
[2] Simple Matter Of Routing
----------------------------------------------------------------------
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
The information contained in this e-mail message is intended only for
the personal and confidential use of the recipient(s) named above. This
message may be an attorney-client communication and/or work product and
as such is privileged and confidential. If the reader of this message
is not the intended recipient or an agent responsible for delivering it
to the intended recipient, you are hereby notified that you have
received this document in error and that any review, dissemination,
distribution, or copying of this message is strictly prohibited. If you
have received this communication in error, please notify us immediately
by e-mail, and delete the original message.
----------------------------------------------------------------------
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
