i am running a DS20E with VMS 7.3-2 and Pathworks.We connect using telnet. I have a configured a 2nd DS20E box with same operating system/pathworks with different node name and IP address. When this 2nd server is placed on the network it crashes some of the original servers telnet sessions and the new servers telent sessions dont appear to work? should the subnet mask and/or broadcast IP be the same in both machines? any help please!
>>> I have a configured a 2nd DS20E box with same operating system/pathworks with different node name and IP address.
Did you do a fresh operating system installation or did you use a copy of the existing system? If you're using a copy of the first DS20e, you'll also need to update the DECnet address. DECnet sets the MAC address based on the address which may cause some interesting network behavior. See the VMS FAQ at Hoffmanlabs.com. http://64.223.189.234/node/589
Of course you've also made sure to update the license database with the appropriate products for your new system if this is a copy.
Andy
If you don't have time to do it right, when will you have time to do it over? Reach me at first_name + "." + last_name at sysmanager net
If telnet sessions are tipping over, there's probably an address collision, or a routing error of some sort, that's been introduced here. There are some somewhat less likely triggers potentially lurking here, such as a screaming (failed) network controller, or a cable fault or such. And it's easy to miss an address collision on a secondary controller, too.
As for whether subnet mask and the broadcast address are the same, all nodes within a particular subnet typically share those values. The hosts will typically also share a default route and some other values.
If there's a VLAN and addresses are messed up, all bets are off; all sorts of weirdness can arise as the VLANs try to deal with the address collision.
That this subnet question is being asked could indicate some unfamiliarity with IP networking. For one form of that and as applied to OpenVMS, please see the introductory manual in the TCP/IP Services documentation.
If the second AlphaServer DS20e system disk was cloned from the first, then you may want to read this discussion on the various spots where the node name and node address can lurk: http://64.223.189.234/node/589
>>Did you do a fresh operating system installation or did you use a copy of the existing system? If you're using a copy of the first DS20e, you'll also need to update the DECnet address. DECnet sets the MAC address based on the address which may cause some interesting network behavior. See the VMS FAQ at Hoffmanlabs.com. http://64.223.189.234/node/589
Hoff, yes i used a copy of the existing system. do i still need to update the decnet address even if im using pathworks? not using decnet at all?
As noted, having the same DECnet addresses can play havoc, particularly since the MAC address of a DECnet node is reset to a formula that includes the DECnet node number.
If this is the case, I would suspect that the ARP tables are getting confused. Suggestion, verify the contents of the ARP tables on the last hop router.
If my suspicion is correct, the SCSID and DECnet node address need to be changed in concert (at the same time).
Please remember to change the SCSID in the files used by AUTOGEN to prevent a future recurrence.
you should just be able to change SCSSYSTEMID in sys$system:modparams.dat, and rerun sys$update:autogen.com to set a new value, as you said that you are not using DECnet at all. Is it even installed?
you should just be able to change SCSSYSTEMID in sys$system:modparams.dat, and rerun sys$update:autogen.com to set a new value, as you said that you are not using DECnet at all. Is it even installed?
My general recommendation is to set the SCSSYSTEMID to a value which is a reasonable DECnet address.
There are many situations in which it is particularly handy to have DECnet connectivity between OpenVMS systems in a multimachine environment. Setting the address to a reasonable value makes it that much easier to enable DECnet without requiring changes and reboots.
thanks to everyone for their help on this thread my 1st time ive used this forum and very impressed many thanks all seems to be working correctly now - the scssystemid was the problem cheers Robert
