3 Mar
2020
3 Mar
'20
8:16 p.m.
On Mar 3, 2020, at 1:13 PM, Thomas DeBellis
<tommytimesharing at gmail.com> wrote:
You may be talking about a number of things here. DECnet node numbers are something
(very) vaguely like IP tuples, except with half the bits and fixed fields. The upper 6
bits constitute the area, the lower 10 bits constitute the number within area. This is
what I recall:
? If the node number's name is not defined to other systems, then many user level
programs will not be able to see if. Tops-20 won't able to build a connection.
Interesting. It depends on the application API. For example, in RSTS the "node
name" argument can contain a number in string form, which lets you connect by
address. But in some places in NCP things don't work if there isn't a name for
the node. I would call that a bug.
? Phase II DECnet used node names directly, I think.
Yes, though it also mentions node addresses. The spec requires a value between 2 and 240,
with no explanation why. The address appears in the Node Init message, but nowhere else
that I can see.
? If the number is the same as another system in
different area, then everything is fine except for 1.
That isn't a duplicate address. The address is a 16 bit value, not a 6 or 10 bit
value. If some of the bits are the same but others aren't, you have two different
addresses.
? If the number is the same as another system in the
same area, then somebody will become 'unhappy'.
? I don't remember how the adjacency is reported for point-to-point.
? If you think of MAC address clash on the same Ethernet segment as opposed to different
segments, you may appreciate a similarity.
Two nodes on the same Ethernet (not just segment but bridged also) will result in a
duplicate Ethernet address. DECnet doesn't define anything that checks for this.
Depending on the implementation, you might see it as an "adjacency" to your own
node address on a circuit. The same issue appears if you have a router with multiple
Ethernet interfaces and you attach those to the same Ethernet. Phase V of course fixes
this by not using a MAC address derived from the node address. So does Phase IV Prime,
but implementations of that are rare at best.
If the multiple nodes are connected to point to point links, or to disjoint Ethernets,
then as far as DECnet is concerned that's just one node reachable via several paths.
That ability is of course intentional -- a router can be reached on any of its interfaces.
A duplicate address essentially looks like a partitioned node. Other nodes would see one
or the other of the two, depending on which is closer (by path cost).
? I don't remember the finer details of the
differences between a level 1 and 2 router.
If one of the duplicate-address nodes is a level 2 router but the other isn't, then
the one that is will show in entry 0 of the routing tables as a possible "nearest L2
router". That will work just fine.
If both are level 2 routers, then for the out of area routing they just act as redundant
L2 routers offering out of area service. The usual rule that an area must not be
partitioned applies, of course.
That brings up a particularly nasty case. Suppose you have an L2 router that duplicates
someone else's address, and in fact it isn't connected into the area its address
says it belongs in. The scenario of "I accidentally booted up an old node"
could do this. If the rogue node isn't connected to other L2 nodes, that's benign
because its L2 services will be turned off -- an L2 router only offers out of area service
if it has out of area circuits that are up. But if the rogue happens to be connected to
some other L2 router, then it would claim connectivity to its area in its L2 routing
messages. That would make the entire area (except the rogue node itself) effectively
unreachable to anyone who has a lower cost L2 path to the rogue than to the real area.
paul