Linux on 390 Port <[EMAIL PROTECTED]> wrote on 09/08/2004 01:52:39 PM:
> > The target node, 'Phalen' already KNOWS what it's DNS name > > and IP address > > are. > > For *one* interface, agreed. It looks to me like WAS is looking at all > the interfaces, and not getting info for some of them. I'm assuming that > both machines are connected to the same hipersocket LAN -- am I way off? Well both machines have their own device addresses, and unique IP for their hipersocket address. Are we doing that wrong? I mean we have 3 z/os Images on the z900, and VM and all my penguins. For illustration sake (not the real devices cuz I don't wanna look that up) z/os 1 has devices 1001,1002,1003 and hipersocket IP of 192.168.252.1 z/os 2 has devices 1004,1005,1006 and hipersocket IP of 192.168.252.2 z/os 3 has devices 1007,1008,1009 and hipersocket IP of 192.168.252.3 VM itsel has devs 100A,100B,100C and hipersocket IP of 192.168.252.10 Penguins have all their devices mapped to 8000,8001,8002 but in actuality are: (my penguins are named after minnesota lakes in case you all were wondering) calhoun 100D,100E,100F and hipersocket IP of 192.168.252.12 nokomis 1010,1011,1012 and hipersocket IP of 192.168.252.13 pepin 1013,1014,1015 and hipersocket IP of 192.168.252.14 phalen 1016,1017,1018 and hipersocket IP of 192.168.252.15 pequot 1019,101a,101b and hipersocket IP of 192.168.252.16 If that's not the right wayt to set things up, then perhaps that is part of the problem. > > > There is NO way that WebSphere on 'Calhoun' can learn about > > what the IP > > address of the hipersocket on Phalen is. Phalen, in the > > process of being > > federated HAS to tell the process on Calhoun about itself, > > including the IP > > address of the ethernet interface it is using. It reports the wrong > > information, and of course, the sanity check in the process running on > > Calhoun fails. > > I guess I'm thinking that it may actually *be* using the HSI interface > if it got the interface info during the query, and thus is barfing on > not having the host info. If the HSI interfaces are in the same subnet > and the other interfaces are not, the IP code may legitmately be > preferring the shorter (same subnet vs different subnet) route. it may very well be doing that, but again, I had the hsi devices ahead of the eth0 devices in the chandev.conf file during installation. Unfortunately, I am not in a position to federatre another pair of penguins into a multi-cell node at the moment, and our WebSphere guy isn't wanting to experiment on the production system we just built.... > > > Why are you not asking whether or not this interface is > > correct. > > Correct is a relative term here. By metric (if the HSI interfaces are on > the same subnet), it's picking the "best" route, regardless of naming. Both the HSI interfaces and the Ethernet interfaces are on their own subnets. All the GB ethernet devices are on a xxx.xx.100.x subnet. All the hipersocket devices are on a 192.168.252.x subnet. So the only path difference to IP is one is memory and one is the backplane of the OSA card. > > This of course, only becomes an issue if you 1) define the > > hipersocket interface before installing WebSphere and 2) > > whether or not you > > made the changes to chandev.conf so that the entry that > > corresponds to hsi1 > > is after the entry for eth0. > > Could be. I'm setting up a test now to see what happens. The messages > still tell me that somehow it's using another interface than you think > it is, and it can't get the info for the interface it is actually using. > What happens if you put a name for the HSI interface into /etc/hosts? That didn't even occurr to me during the process of resolving this, and again, I'm not in a position to go off and federate a second node into another websphere cell. ---------------------------------------------------------------------- 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
