Cisco IOS "ping decnet" vs. NCP (loop?) on OpenVMS/VAX 7.3 DECnet-IV

[Supratim Sanyal]

The "ping decnet xx.yyy" command from Cisco's routers running IOS is
very fast and can ping nodes that do not have NML at all (e.g. other
Cisco routers) or have their executor shut down.

Is there a equivalent NCP command on OpenVMS/VAX 7.3 DECnet-IV?

CISCO7206VXR>ping decnet 1.550

Type escape sequence to abort.
Sending 5, 100-byte DECnet echos to atg 0 area.node 1.550, timeout is 5
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/36 ms

Thank you
Supratim Sanyal
QCOCAL::SANYAL

[Stephen Hoffman]

On 2019-02-21 04:43:34 +0000, Supratim Sanyal said:

> The "ping decnet xx.yyy" command from Cisco's routers running IOS is
> very fast and can ping nodes that do not have NML at all (e.g. other
> Cisco routers) or have their executor shut down.
>
> Is there a equivalent NCP command on OpenVMS/VAX 7.3 DECnet-IV?

DECnet doesn't offer an equivalent to ping, and never has.

I'd suspect that Cisco is using the mirror object here (underneath
LOOP), though would have to packet-capture for evidence of that.
Alternatively, try disabling the mirror object on a target DECnet host,
and repeating the test.

The NCP command, and DTS/DTR testing tool:
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c04622748

A directory of DECnet Phase IV manuals and a separate directory of
DECnet architecture manuals are available on different versions of the
OpenVMS Freeware.

Skim the DECnet Phase IV architecture manuals for details of what Cisco
would be using, if not the mirror object.

A little light reading on porting DECnet Phase IV, while it's still
available at HP:
http://www.hpl.hp.com/hpjournal/dtj/vol4num4/vol4num4art11.pdf

*Now ponders whether it'd be possible to use the mirror object in a
DECnet analog to an amplification attack.*

--
Pure Personal Opinion | HoffmanLabs LLC

[Supratim Sanyal]

On 2/21/19 11:39 AM, Stephen Hoffman wrote:
> I'd suspect that Cisco is using the mirror object here (underneath
> LOOP), though would have to packet-capture for evidence of that.
> Alternatively, try disabling the mirror object on a target DECnet host,
> and repeating the test.

Does the executor not have to be up for the mirror object to be invoked
to respond? Cisco is managing to ping nodes that even have the executor
shut down. As an example, right now:

From another VMS host:

$ mc ncp tell 29.100 show exec
%NCP-F-CONNEC, unable to connect to listener
-SYSTEM-F-SHUT, remote node no longer accepting connects

*BUT* from a Cisco on the exact same network:

CISCO7206VXR-MOKSHA>ping decnet 29.100

Type escape sequence to abort.

Sending 5, 100-byte DECnet echos to atg 0 area.node 29.100, timeout is 5
seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/112/128 ms

I will try capturing some packets and post them a bit later.

[Stephen Hoffman]

On 2019-02-21 17:24:34 +0000, Supratim Sanyal said:

> On 2/21/19 11:39 AM, Stephen Hoffman wrote:
>> I'd suspect that Cisco is using the mirror object here (underneath
>> LOOP), though would have to packet-capture for evidence of that.
>> Alternatively, try disabling the mirror object on a target DECnet host,
>> and repeating the test.
>
> Does the executor not have to be up for the mirror object to be invoked
> to respond? Cisco is managing to ping nodes that even have the executor
> shut down. As an example, right now:

Scan for the mirror object.

> I will try capturing some packets and post them a bit later.

Um, okay. Not on my behalf, I hope.

Go read the DECnet specs.

[Supratim Sanyal]

It appears Cisco is sending out a "DNA NSP message: Link service message
(0x10)" to which the remote node is responding with "DNA NSP message:
Disconnect confirm (0x48)" with "Reason for disconnect: Unknown
(0x0029)", constituting one successful "Ping".

Can this exchange be done using the NCP command line on OpenVMS?

Ping source (Cisco Router) : 1.579 / AA-00-04-00-43-06
Ping target (OpenVMS/VAX 7.3): 29.100 / AA-00-04-00-64-74

----------------
Outgoing packet:
----------------
Frame 3: 116 bytes on wire (928 bits), 116 bytes captured (928 bits) on
interface 0
Interface id: 0 (vde-decnet-tap1)
Interface name: vde-decnet-tap1
Encapsulation type: Ethernet (1)
Arrival Time: Feb 21, 2019 17:39:27.947909852 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1550770767.947909852 seconds
[Time delta from previous captured frame: 0.626152916 seconds]
[Time delta from previous displayed frame: 0.626152916 seconds]
[Time since reference or first frame: 1.943204371 seconds]
Frame Number: 3
Frame Length: 116 bytes (928 bits)
Capture Length: 116 bytes (928 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:dec_dna]
Ethernet II, Src: DecLocal_00:43:06 (aa:00:04:00:43:06), Dst:
DecLocal_00:2f:06 (aa:00:04:00:2f:06)
Destination: DecLocal_00:2f:06 (aa:00:04:00:2f:06)
Address: DecLocal_00:2f:06 (aa:00:04:00:2f:06)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Source: DecLocal_00:43:06 (aa:00:04:00:43:06)
Address: DecLocal_00:43:06 (aa:00:04:00:43:06)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Type: DEC DNA Routing (0x6003)
DEC DNA Routing Protocol
Routing flags: 0x0e
.... .11. = Long data packet format: 0x3
.... 1... = Return to Sender Request: Yes
...0 .... = Packet on return trip: No
..0. .... = Intra-ethernet packet: No
.0.. .... = Discarded packet: No
Destination Address: DecLocal_00:64:74 (aa:00:04:00:64:74) (29.100)
Source Address: DecLocal_00:43:06 (aa:00:04:00:43:06) (1.579)
Next level 2 router: 0x00
Visit count: 0x01
Service class: 0x00
Protocol type: 0x00
DNA NSP message: Link service message (0x10)
Destination node: 0x7464
Source node: 0x0643
.... 0000 0000 0000 = Message number: 0
...0 .... .... .... = Delayed ACK allowed: No


---------------
Incoming packet
---------------
Frame 4: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on
interface 0
Interface id: 0 (vde-decnet-tap1)
Interface name: vde-decnet-tap1
Encapsulation type: Ethernet (1)
Arrival Time: Feb 21, 2019 17:39:28.069274170 UTC
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1550770768.069274170 seconds
[Time delta from previous captured frame: 0.121364318 seconds]
[Time delta from previous displayed frame: 0.121364318 seconds]
[Time since reference or first frame: 2.064568689 seconds]
Frame Number: 4
Frame Length: 60 bytes (480 bits)
Capture Length: 60 bytes (480 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:dec_dna]
Ethernet II, Src: DecLocal_00:2f:06 (aa:00:04:00:2f:06), Dst:
DecLocal_00:43:06 (aa:00:04:00:43:06)
Destination: DecLocal_00:43:06 (aa:00:04:00:43:06)
Address: DecLocal_00:43:06 (aa:00:04:00:43:06)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Source: DecLocal_00:2f:06 (aa:00:04:00:2f:06)
Address: DecLocal_00:2f:06 (aa:00:04:00:2f:06)
.... ..1. .... .... .... .... = LG bit: Locally administered
address (this is NOT the factory default)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
Type: DEC DNA Routing (0x6003)
DEC DNA Routing Protocol
Routing flags: 0x06
.... .11. = Long data packet format: 0x3
.... 0... = Return to Sender Request: No
...0 .... = Packet on return trip: No
..0. .... = Intra-ethernet packet: No
.0.. .... = Discarded packet: No
Destination Address: DecLocal_00:43:06 (aa:00:04:00:43:06) (1.579)
Source Address: DecLocal_00:64:74 (aa:00:04:00:64:74) (29.100)
Next level 2 router: 0x00
Visit count: 0x01
Service class: 0x00
Protocol type: 0x00
DNA NSP message: Disconnect confirm (0x48)
Destination node: 0x0643
Source node: 0x7464
Reason for disconnect: Unknown (0x0029)

[Stephen Hoffman]

On 2019-02-21 22:31:36 +0000, Supratim Sanyal said:

> It appears Cisco is sending out a "DNA NSP message: Link service
> message (0x10)" to which the remote node is responding with "DNA NSP
> message: Disconnect confirm (0x48)" with "Reason for disconnect:
> Unknown (0x0029)", constituting one successful "Ping".
>
> Can this exchange be done using the NCP command line on OpenVMS?

Which part of "no" was unclear? Write some code.

[Supratim Sanyal]

OK, it is clear whats to be done. Will assign this to a developer.

Thank you.

[Robert A. Brooks]

What does this DECnet ping actually tell you? Given that it still
works if the executor state is off (or shut), all you know is that
DECnet was up at some point in the past. Yes, you know that the node
is powered on, and if that's good enough, then have at it.

Note that a node that was running Phase IV, but is currently at the console
prompt, may still show as available at the physical layer on the network, due
to the fact that the adapter physical address was changed to AA:00:04:00:XX:XX.
In this case, however, you would not get any NSP-layer response.

This may be adapter-specific behaviour, but I saw this happen with DEMNA's
on VAX 6000-class systems back in the day.

--
-- Rob

[Tim Sneddon]

Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
> On 2/21/2019 6:52 PM, Supratim Sanyal wrote:
>> On 2/21/19 6:47 PM, Stephen Hoffman wrote:
>>> On 2019-02-21 22:31:36 +0000, Supratim Sanyal said:
>>>
>>>> It appears Cisco is sending out a "DNA NSP message: Link service message
>>>> (0x10)" to which the remote node is responding with "DNA NSP message:
>>>> Disconnect confirm (0x48)" with "Reason for disconnect: Unknown (0x0029)",
>>>> constituting one successful "Ping".
>>>>
>>>> Can this exchange be done using the NCP command line on OpenVMS?
>>>

>>> Which part of "no" was unclear??? Write some code.

>>>
>>
>> OK, it is clear whats to be done. Will assign this to a developer.
>
> What does this DECnet ping actually tell you? Given that it still
> works if the executor state is off (or shut), all you know is that
> DECnet was up at some point in the past. Yes, you know that the node
> is powered on, and if that's good enough, then have at it.

I think Cisco were providing the equivalent of an IP ping for their
routers. They provide something similar for most other protocols:

a12rtr#ping ?
WORD Ping destination address or hostname
appletalk Appletalk echo
atm ATM echo
clns CLNS echo
decnet DECnet echo
ethernet Ethernet echo
ip IP echo
ipv6 IPv6 echo
ipx Novell/IPX echo
srb srb echo
tag Tag encapsulated IP echo
<cr>

>
> Note that a node that was running Phase IV, but is currently at the console
> prompt, may still show as available at the physical layer on the network, due
> to the fact that the adapter physical address was changed to AA:00:04:00:XX:XX.
> In this case, however, you would not get any NSP-layer response.
>

The packet that Supratim captured seems to suggest that there is an NSP-layer
repsonse (copied from above...)

'...to which the remote node is responding with "DNA NSP message:
Disconnect confirm (0x48)" with "Reason for disconnect: Unknown (0x0029)",'

I'm guessing this is pretty standard Phase IV behaviour as it works for
Cisco routers, VAX and Alpha VMS systems (mine are running Phase V/OSI), RSX
and RSTS/E. Interestingly enough my Tru64 UNIX system does not respond and it
is operating in Phase IV compat. mode.

Regards, Tim.

[BlackCat]

Just for completeness DECnet PhaseV (Network Layer based on ISO8473, see also rfc1575) has an OSI/DECnetV ping function. Unfortunately the initiator part is only implemented in "DECnet for Tru64" (see oping). The responder part is present in both "DECnet for Tru64" and "DECnet for OpenVMS".

It is something I have asked for jonks. Unfortunately no one at HP was listening. :-((

Maybe someone at VSI is listening?

John

[Robert A. Brooks]

Someone at VSI is always listening :-)

John, please send us an official enhancment request.

How many micro-fortnights in a jonk?

--
-- Rob

[BlackCat]

On Friday, 22 February 2019 15:43:31 UTC+1, Robert A. Brooks wrote:
> On 2/22/2019 6:33 AM, BlackCat wrote:
> > Just for completeness DECnet PhaseV (Network Layer based on ISO8473, see also
> > rfc1575) has an OSI/DECnetV ping function. Unfortunately the initiator part
> > is only implemented in "DECnet for Tru64" (see oping). The responder part is
> > present in both "DECnet for Tru64" and "DECnet for OpenVMS".
> >
> > It is something I have asked for jonks. Unfortunately no one at HP was
> > listening. :-((
> >
> > Maybe someone at VSI is listening?
>
> Someone at VSI is always listening :-)
>

I suspected as much. ;-)

> John, please send us an official enhancment request.
>

Will do. I assume I can send it to sup...@vmssoftware.com ?

> How many micro-fortnights in a jonk?

You were right to question this, it should read yonks !
see https://en.oxforddictionaries.com/definition/yonks

John

[Stephen Hoffman]

On 2019-02-22 04:17:16 +0000, Robert A. Brooks said:

> What does this DECnet ping actually tell you?

This seems more of a "we must have a ping because they have a ping" case.

The DECnet specs have what DEC intended.

Whether this behavior is something that was intended, or something that
involves a creative interpretation of the specs?

This wouldn't be the first creative interpretation of a network spec, either.

> Note that a node that was running Phase IV, but is currently at the
> console prompt, may still show as available at the physical layer on
> the network, due to the fact that the adapter physical address was
> changed to AA:00:04:00:XX:XX. In this case, however, you would not get
> any NSP-layer response.
>
> This may be adapter-specific behaviour, but I saw this happen with
> DEMNA's on VAX 6000-class systems back in the day.

DEBNA or DEBNT (or both?) had similar (mis)behavior, and DECnet on
other hosts would still report address collisions with the "collided"
host shut down to the console.

IIRC, fix for most of these was a firmware update and/or a console bus
reset, and a manual bus reset at the console as a workaround.

This is all ~30 years ago, too.

[Dave Froble]

I would consider who originated this. Cisco. Now, I doubt Cisco cared
if a computer was working, but cared whether there was a good network
link. That's what they do, networking.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486