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

[Maurizio Rondina]

The Decnet network of site B, have the following terminal servers

1.401 90L+
1.402 90M
1.405 90L+
1.406 90L+
1.408 90L+
1.409 90L+

Some have address beginning with 00-.. others with 08-...

I try on all six, but none of them replies to
MC NCP LOOP NODE

I try to reach all the 6 address with command
MC NCP CONNECT NODE 1.xxx

only 1.408 respond.

The command set host/mop/circ=eia-0/add=00.. doesn't work, it reply with
%DCL-W-ACTIMAGE, error activating image NET$CCR image not found...

May be that when was executed NETCONFIG to someone of the questions of creation DECNET ACCOUNT, FAL, PHONE, etc. was replied in wrong mode.

Maybe that models of terminal servers, aren't manageable remotely. Note, they aren't 90TL, only 90L+ with only LAT protocol, and one 90M.


Now i ask to the customer, to verify very very well with 4 eyes, the hardware address, to avoid confusion between 8 and B, 0 and O, and so on. I think there was a mistake, on commands defining Decnet Database (DEFINE NODE .... HARDWARE .....), or all the terminal servers (except 1.408) have local problems (serial no. too old).

I think that now, after i correct the name of the circuit from SVA-0 to EIA-0, the server and the network work fine.

I will inform you about the reply of the customer, and I will assign points to you. Thanks.

[Bob Blunt]

First and foremost the NCP database definitions for the two terminal servers HAVE to have the correct information on both nodes. This means that each node's NCP permanent and volatile databases have to have the right stuff. In order for the "MC NCP CONNECT NODE 1.401" command to work properly the following minimum info MUST be defined in the database for each terminal server:

node address
node name
service circuit
hardware address (the MAC addr)

It helps if the terminal servers are defined with identical node name, node address and hardware address. If they're not consistant then you either can't connect from one node or you'll connect to the wrong terminal server. You can see the permanent database definitions for your terminal servers by entering (for example):

"LIST NODE 1.401 CHAR"

on both nodes. The service circuit MUST match the hardware that each host uses, so if one uses a SVA-0 circuit in it's database should show SVA-0 as the service circuit. If the other node has circuit EWA-0 its nodes should have EWA-0 for their service circuit.

The acid test for connectivity would be to issue the following command from both nodes, but you must have the correct destination MAC address and service circuit for each host:

"MC NCP CONNECT VIA SVA-0 PHYSICAL ADDRESS 08-00-2B-0F-FF-13"

Proper definition of the nodes in the NCP permanent database means you don't have to remember the gory details but you have to keep the information up-to-date or it stops working. Keeping that information updated and consistant can be painful but without the effort you're making yourself more work.


Hope that helps

bob

[Wim Van den Wyngaert]

It seems that set ho/mop was only implemented for decnet+. Didn't know that (we only have +).

Wim

[Wim Van den Wyngaert]

And I was wrong on the suspicion with 00. We have 08 and 00 too. I thought 00 was reserved for decnet nodes and that all dec stuff was 08.

Wim

[Maurizio Rondina]

To Bob:

In a NCPSTART.COM file whose execute on the startup procedure the system had the following NCP commands for each terminal server

DEFINE NODE 1.106 NAME T406 HARDWARE 08-00-.... SERVICE CIR EIA-0
SET NODE 1.106 NAME T406 HARDWARE 08-00-.... SERVICE CIR EIA-0
SET NODE T406

So we can use the command
NCP CONNECT NODE with 1.406, with T406 or with Hardware Addres, as we want.

To Wim:
i never use decnet+, only decnet fase IV

[Wim Van den Wyngaert]

Both address ranger belong to DEC.
http://standards.ieee.org/regauth/oui/oui.txt

Learned again. I thought only the first 4 address positions were used to denote the supplier. And it's 6.

Wim

[Bob Blunt]

Maurizo, your last response is confusing. In your original question you state that you're unable to communicate to a terminal server from a specific node and your example output from NCP shows inconsistancies between definitions for those terminal servers from the separate permanent databases. In your last response you show a portion of a startup command procedure where you're DEFINE-ing and SET-ing terminal servers.

Your NCP definitions have to be consistant across all your nodes or you can't expect consistant behavior, that's first. Second, there should never be any reason that you need to DEFINE and SET node characteristics for a normal system running DECnet during each boot. The permanent database retains the configuration data for that exact purpose. Aren't you getting errors during startup from this?

When you have consistant definitions and your attempts to connect from some nodes still fail, then you look at connectivity or network configuration as Hoff suggested.

[Hoff]

Maurizio: consider getting somebody in to review and to tailor this DECnet Phase IV network.

That the startup is issuing SET and DEFINE commands at startup is clearly indicating some DECnet network cleanup is needed, and that all DECnet routing traffic is being sent over the inter-site link are probably not goodness. There are configuration and operational improvements available here, above and beyond (likely) determining why the inter-site link is blocking the MOP protocols.

And it could be that MOP is simply lit on the wrong network controller(s), too.

Stephen Hoffman
HoffmanLabs LLC

[Colin Butcher]

Hello Maurizio,

Let me briefly summarize:

DECservers and other "MOP clients" do not run DECnet. The fact that they exist at all in the DECnet Phase IV node database is a kludge to associate them with a load image.

The protocols (at ethernet layer 2) you're using for DCservers are usually: MOP (boot / downline load support), Remote Console (NCP CONNECT to a remote device's virtual console port) and LAT (terminal access to systems and reverse LAT printer access from systems).

In addition you're probably running DECnet and TCP/IP.

I recommend that you remove the DECservers from the DECnet databases and use LANCP instead. It does a better job of MOP and Remote Console. If you need to manage multiple DECservers then get TSM (Terminal Server Manager) from the Freeware CD set).

I'd also recommend that you consider moving to DECnet Phase V (aka DECnet-Plus).

It sounds to me as if your WAN doesn't pass all the protocols: DECnet, MOP, Remote COnsole, LAT etc. If you want to continue woth this equipment then you need to fix that. If you can change your equipment then move to TCP/IP as the protocol between the DECservers and the systems, update to a version of terminal server firmware that supports BOOTP and then set everything up carefully.

It's not that hard, but is does require care and attenmtion.

Cheers, Colin,.

[Wim Van den Wyngaert]

Colin,

1 decserver worked so all protocols must be working.

Wim

[Colin Butcher]

Hello Wim,

That's true locally, but the remote site needs to have all those protocols enabled on the bridge / router devices at each end of the WAN link.

If it's a TCP/IP only WAN link then the only solution is to "set host" or "telnet" to a node at the remote site and use NCP CONNECT in a LAN environment, not a WAN.

It's all good fun and becoming a more common problem as people migrate from extended LANs using bridging to IP only WAN services.

Cheers, Colin (http://www.xdelta.co.uk).

[Maurizio Rondina]

sorry, but i still wait for the customer reply.

Last update is that only T402 (90M) and T407 (90L+) are not reachable on his own LAN, from NCP CONNECT NODE.

I think, that the mac-address printed on the box of these terminal server, was wrong.

I asked to the customer, to connect with a terminal locally, and inquire from the local command prompt the mac-address, to see if it correspond to the one printed on the box.

...unfortunately now they have no hurry! we must wait.

[Maurizio Rondina]

The 2 terminal server unreachable are
T402 Hardware 00-60-6D-9B-D8-A3
T407 Hardware 00-00-F8-50-12-36

I try search on

http://www.coffer.com/mac_find/
this is the result:


Search results for "00-60-6D-9B-D8-A3"
MAC Address
Prefix Vendor
00606D Digital Equipment Corp.


Search results for "00-00-F8-50-12-36"
MAC Address
Prefix Vendor
0000F8 Digital Equipment Corporation (DEC)

Now I'm sure that mac-address are correctly and that there is a local problem on these 90L+ and 90M. The customer don't know as manage locally these units, so I will can verify the situation only on-site, i don't know when... Thanks for all.