[HECnet] Multinet peerings...?

[Robert Jarratt]

> -----Original Message-----
> From: owner-hecnet at Update.UU.SE [mailto:owner-
> hecnet at Update.UU.SE] On Behalf Of Mark Pizzolato
> Sent: 15 January 2016 03:06
> To: hecnet at Update.UU.SE
> Subject: RE: [HECnet] Multinet peerings...?
> 
> On Thursday, January 14, 2016 at 6:42 PM, Johnny Billquist wrote:
> > On 2016-01-15 03:25, Brian Hechinger wrote:
> > >
> > >> 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).
> > >
> > > 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.

Indeed it can. It supports Ethernet, the Bridge, and DDCMP over TCP. With the latter, it can talk to another instance of the router, or to SIMH.

Regards

Rob


> 
> - Mark