15 Jan
2016
15 Jan
'16
4:05 a.m.
On Thursday, January 14, 2016 at 6:42 PM, Johnny Billquist wrote:
On 2016-01-15 03:25, Brian Hechinger wrote:
And this is what I was (and always have been) thinking. Make ?shorter?
> ethernet segments that are less geographically diverse. Put routers between
> them. That should solve most problems, no?
Yes. This is actually just the traditional way networks are designed.
Ethernet is a LAN - as in local. It's not designed for long haul connections. It
only works because the internet today have pretty amazing capacity
compared to the 80s.
But to get a more traditional topology, we need the routers in between
somehow - and the WAN links.
The problem with that have been that much DECnet gear only supports
various links that best would be described as arcane by todays standards, in
addition to the ethernet. How many use X.25 nowadays? Or synchronous
serial lines?
Well, if you were running a Cisco box, you could tunnel DECnet over GRE.
Not everyone have one of those. The other option more "generally"
available was VMS machines running Multinet, as that supported DECnet
links carried over IP.
One option that is slowly becoming more and more plausible are specific
routers, such as Pauls python router, and Rob Jarrats implementation.
Certainly, given an already working internet connection, it would never
make sense for anyone to setup a synchronous serial line again, BUT folks
who are running simh PDP11 or VAX systems can use the traditional
DMC/DMR links for point to point WAN connections. Transport can either
be TCP or UDP.
I'm pretty sure that Rob Jarratt's router can be an endpoint for one of
these connections.
- Mark
> On Jan 14, 2016, at 8:03 PM, <Paul_Koning at Dell.com>
<Paul_Koning
at Dell.com> wrote:
>
>
>> On Jan 14, 2016, at 4:40 PM, hvlems at zonnet.nl wrote:
>>
>> ...
>>> Can the bridge program detect whether there are area routers for the
dame area at both ends and favor the local one, possibly block advertising of
the remote area router?
I tried blocking traffic from a node in one area from getting to
another area, with the exception of packets from area routers.
Unfortunately, it does not work. DECnet can be clever about local
ethernet connectivity. If you are on the same ethernet segment,
nodes can communicate directly with other nodes on the same ethernet
segment, even if they are endnodes, and this exen extends to nodes
on different areas. So such filtering in the bridge cause
communication to fail for endnodes on the ethernet segment, when the
destination is on the same ethernet, even if in a different area.
DECnet expects a "transitive Ethernet" -- if A can talk to B and B can talk to
C, A must be able to talk to C. That's actually a common assumption, other
network protocols do the same. DECnet is a bit unusual in that it explicitly
verifies this property, at least for routers -- that's why router hellos have the
router list in them. We put that in because we had run into some defective
Ethernets that were non-transitive, causing very strange misbehavior until
this protocol mechanism was added.
End nodes have an on-Ethernet cache: if X talks to Y and both are on the
same Ethernet, they will do it directly. From the first packet if there are no
routers; after the initial round-trip if there are. If you create a non-transitive
Ethernet -- which is what filtering does -- this will fail. There is no
workaround. If you don't want all the nodes on an Ethernet to have direct
communication, the only solution is to split it into two separate Ethernets,
interconnected by a router (not a bridge).