[HECnet] Multinet peerings...?

[Robert Jarratt]

> -----Original Message-----
> From: owner-hecnet at update.uu.se [mailto:owner-hecnet at update.uu.se]
> On Behalf Of Johnny Billquist
> Sent: 15 January 2016 03:12
> To: hecnet at update.uu.se
> Subject: Re: [HECnet] Multinet peerings...?
> 
> On 2016-01-15 04:05, Mark Pizzolato wrote:
> > 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.
> 
> Well, I'm thinking actual, physical machines, and not emulated ones... :-)


One thing I would like to do one day is to get my router to talk to a physical DMC/DMR, but I am not really set up  for that (yet).

Regards

Rob


> 
> 	Johnny
> 
> --
> Johnny Billquist                  || "I'm on a bus
>                                    ||  on a psychedelic trip
> email: bqt at softjar.se             ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol