Differenze between NCP on Openvms Versions?

[Maurizio Rondina]

I have a network with two OpwnVms Systems, the first had dacnet fase IV address 1.3, the second had addres 1.7.

The One with address 1.3 (whose had OpenVms versione 7.3) can reach Terminal Servers 90L and 90M (eg. with address 1.401 and 1.701), remotely with the following DecNet command

$ MC NCP CONNECT NODE 1.401

and the prompt of the terminal server is given, so I can configure remotely this 90L.

The one with address 1.7 (with OpenVms 8.3) cannot reach for remote management none Terminal Server.

when i give the same command

$ MC NCP CONNECT NODE 1.401

nothing happen, the "$" prompt appear just after.

Have you any suggestion?

[Steven Schweda]

On each system:

NCP SHOW EXECUTOR

[Hein van den Heuvel]

Just manage it from 1 of the nodes?

I could be wrong but does the connection to the terminal server use the MAC address.
So that woudl have to be set (defined in the permanent) database.

On both nodes execute:

NCP SHOW NODE 1.401 CHAR
Are there lines with: Hardware address = 08-00...

Another guess... did you log out from the first node before trying the second?


Hein.

[Maurizio Rondina]

Now I found that the nodes on system B was defined on circuit SVA-0 (in that case, after the command the system prompt immediately appear and nothing happen, now I modify the nodes on system B with the correct circuit, and the command remain in Wait state until the timeout.

This the actual situation:

System A
$ mc ncp show known nodes
Node Volatile Summary as of 4-JUL-2008 20:50:39
Executor node = 1.3 (A1)
State = on
Identification = DECnet for OpenVMS AXP V7.3
Active links = 2

Node State Active Delay Circuit Next node
Links

1.7 (A4B) EWA-0 0
1.101 (T101) EWA-0 0

$ mc ncp show known circ
Known Circuit Volatile Summary as of 4-JUL-2008 21:13:16
Circuit State Loopback Adjacent
Name Routing Node

EWA-0 on
EWA-1 off

$ mc ncp show node 1.101 char
Node Volatile Characteristics as of 4-JUL-2008 20:59:45
Remote node = 1.101 (T101)
Service circuit = EWA-0
Hardware address = 08-00-2B-9E-45-84

$ mc ncp connect node 1.101
Console connected (press CTRL/D when finished)
->


System B
$ mc ncp show known nodes
Node Volatile Summary as of 4-JUL-2008 20:56:41
Executor node = 1.7 (A4B)
State = on
Identification = HP DECnet for OpenVMS Alpha

Node State Active Delay Circuit Next node
Links

1.3 (A1) EIA-0 0
1.401 (T401) EIA-0 0

$ mc ncp show known circ
Known Circuit Volatile Summary as of 4-JUL-2008 21:13:21
Circuit State Loopback Adjacent
Name Routing Node
EIA-0 on
EIA-1 off

$ mc ncp show node 1.401 char
Node Volatile Characteristics as of 4-JUL-2008 21:14:24
Remote node = 1.401 (T401)
Service circuit = EIA-0
Hardware address = 00-00-F8-52-AE-EC

$ mc ncp connect node 1.401 (it remain in wait state)

NOTE also mc ncp loop node 1.401 remain in wait state

[Hein van den Heuvel]

Hmmm, where does this node T101 enter the picture? I thought you wanted to connect to t401 from both?

So can you connect to t401 from A, but not B?
Or are you only trying to connect from B?
Could T401 simply be unreachable?
Does a local terminal on the pterminal server work?

Did you use to be able to connect before an upgrade (of VMS) but can not connect anymore, or did you add the OpenvVMS versions difference here just to make confuse us?

I see all different Hardware addresses, but expected 2 being the same.

(Also) try TCP?

Hein.

[Hoff]

Climbing very far out onto a limb here with the following series of guesses...

You probably have Cisco switches or other similar managed switches around, and there are probably VLANs and/or VPNs configured, and you will accordingly need to discuss this network access matter with your network management folks.

This probably doesn't involve OpenVMS at all, but rather this is how your network folks have your local VLAN and local switch(es)/router(s) configured.

Your network folks will need to open up MOP 60-01 and 60-02 protocol access.

http://64.223.189.234/node/61

[Maurizio Rondina]

The network of 1.3 and 1.101 and others, is on circuit EWA-0 and is located to SITE A

The network of 1.7 and 1.401 and others, is on circuit EIA-0 and is located to SITE B

each of this two site, has an autonomy administration, managed by different persons.

All the functionality of site A and site B, are well. Servers and Terminals on 90L and PLC on 90M communicate with each other, correctly without problems.

The problem is simply the follow:

The Administrator of the site A, can configure the Terminal server 90L, remotely with MC NCP CONNECT NODE 1.101 or other anywere, directly from his office.

The Administrator of the site B, would want to have the same feature, but he cannot reach remotely 1.401 and others, and so, for any modification he need, he must to go far any time on a phisical terminal locally connected to the specific terminal server.

The Modification that occurred on the site B, is that first there was an Alpha1000 with circuit SVA-0, now there is an Alphaserver DS15 with circuit EIA-0, the terminal servers 90L and 90M are exactly the same. At the change of the server, none changes configuration was made on the 90L and 90M.

[Hein van den Heuvel]

Ok understood. The discussion about area 'a' is just to keep us alert, on our toes. Much like the title.
Yes we know NCP connect can work. Fine.


No reasone what so ever to suspect OpenVMS V8.3 or VMS for that matter.

This could be as simple as a mis-typed Hardware address, or as hard as funky router (as per Hoff).

You have to go back to the basics... like tripel checking the MAC address. Maybe some ping/arp commands?
Also, so try TPC if the area B termsever supports it. Which node system (MOP) loaded it?

Hein.

[Hoff]

DECnet and DECnet routing and DECnet protocols are not related to MOP. So pointing to anything related to DECnet has little to do with MOP. This assuming (as Hein points to) you've checked the basic MAC settings and such.

The salient overlap here is that MOP uses the DECnet databases to store some of its data. But that is not required; you don't need DECnet around to use MOP.

Your DECnet network is already slightly odd, as I'd expect to see two separate sites to be configured in two separate areas. That saves on the management coordination.

But barring full LAN bridging between the sites, it is a most excellent bet here that the inter-site link is simply not passing the MOP protocols.

[Wim Van den Wyngaert]

Why is the 1.401 address beginning with 00 ?
Is set host/mop/circ=eia-0/add=00... working ?

Wim