6 Jan
2018
6 Jan
'18
11:30 p.m.
One of the suggestions that was posted here for how one might connect to HECnet was to
create a GRE tunnel to a cooperative node, using either a Cisco router or an emulation of
one. I don't have any experience with Cisco stuff, and I don't feel enthusiastic
about going down that particular rabbit hole just yet if I can find another approach more
in line with my experience and interests.
I see that there is GRE support in Linux, at least for IP-in-IP tunneling. Do any of
y'all know if Linux's GRE support can tunnel non-IP protocols such as DECnet Phase
IV? So far I've only succeeded in finding documentation about how to set up IP-in-IP
tunneling, and I don't understand what's going on under the hood yet.
Since I want to keep my local DECnet traffic local, my current goal is to set up a
VAX/OpenVMS simulation under SIMH to act as a DECnet area router (and provide other
services to my real VAXen, too). I plan to use a SIMH emulation so I can leave it up all
the time to maintain presence on HECnet without running up a big power bill. My real
VAX-11/730 and other future vintage DECnet-speaking hardware would only graze on electrons
infrequently, and mostly during colder weather.
7 Jan
7 Jan
1:17 a.m.
Hi Mark,
Since I want to keep my local DECnet traffic local, my
current goal
is to set up a VAX/OpenVMS simulation under SIMH to act as a DECnet
area
router (and provide other services to my real VAXen, too).
My approach was to compile SIMH with VDE support, and then use VDE as
the primary DECnet-only switch connecting nine DECnet nodes in my
basement in Washington, DC to a 10th node (CLOUDY) on a VPS in
Kitchener, Ontario, Canada. It works great, VDE basically provides
ethernet ports on the same switch no matter where the ports
geographically are; the virtual ethernet switch extends over SSL, hence
it is pretty secure too.
If the host machine of MIM had VDE installed and shared the public key
with us, we could, in theory, connect all our simulated DECnet nodes to
MIM:: without using Multinet or Johnny's bridge etc.
I am sure you are aware of VDE, but still, here is the link:
http://vde.sourceforge.net/
Best,
Supratim
On 1/6/2018 17:30, Mark J. Blair wrote:
Since I want to keep my local DECnet traffic local, my
current goal is to set up a VAX/OpenVMS simulation under SIMH to act as a DECnet area
router (and provide other services to my real VAXen, too).
2:20 a.m.
On 2018-01-07 01:17, Supratim Sanyal wrote:
Hi Mark,
We could, in theory, connect them all using the bridge as well. But it's
not a good idea. DECnet does not scale well in that way.
Security is not the biggest issue.
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
Since I want to keep my local DECnet traffic
local, my current goal
is to set up a VAX/OpenVMS simulation under SIMH to act as
a DECnet area
router (and provide other services to my real VAXen, too).
My approach was to compile SIMH with VDE support, and then use VDE as
the primary DECnet-only switch connecting nine DECnet nodes in my
basement in Washington, DC to a 10th node (CLOUDY) on a VPS in
Kitchener, Ontario, Canada. It works great, VDE basically provides
ethernet ports on the same switch no matter where the ports
geographically are; the virtual ethernet switch extends over SSL, hence
it is pretty secure too.
If the host machine of MIM had VDE installed and shared the public key
with us, we could, in theory, connect all our simulated DECnet nodes to
MIM:: without using Multinet or Johnny's bridge etc.
2:30 a.m.
On 1/6/2018 20:20, Johnny Billquist wrote:
We could, in theory, connect them all using the bridge
as well. But
it's not a good idea. DECnet does not scale well in that way.
Security is not the biggest issue.
True that. I know first-hand what a mess packets looping back over
ethernet can be.
Still, Mark could patch in all simulated nodes and bridge in all
physical nodes to a VDE switch for local DECnet traffic, and use a
router SIMH node for Multineting to MIM ...
5:20 a.m.
On 2018-01-07 02:30, Supratim Sanyal wrote:
On 1/6/2018 20:20, Johnny Billquist wrote:
Not the only problem either. DECnet over Ethernet means all routing
nodes needs to keep track of all other routing nodes on the ethernet
segment, and they all broadcast packets at regular intervals. And so,
DECnet have a limit on how many routing nodes can be on a segment, which
is somewhat limited. And all nodes (even non-routing ones) broadcast
packets at regular intervals.
And even nodes from different areas take shortcuts with ethernet
sometimes, not even going over routing nodes when talking on the same
ethernet segment.
All in all making it starting to look pretty bad when you get too many
nodes on one ethernet segment.
Packet looping in ethernet is not DECnet specific, and is the reason why
switches implement STP. I was just too lazy to do that with the bridge
program. ;-)
We could, in theory, connect them all using the
bridge as well. But
it's not a good idea. DECnet does not scale well in that way.
Security is not the biggest issue.
True that. I know first-hand what a mess packets looping back over
ethernet can be. Still, Mark could patch in all simulated nodes and
bridge in all
physical nodes to a VDE switch for local DECnet traffic, and use a
router SIMH node for Multineting to MIM ...
Or just use an actual ethernet switch, since he'll need one for the
physical machines anyway.
In the end, he need a router in order to keep local traffic local. And
the router will have one interface towards the local side, which needs
to get on to an ethernet switch in order to connect physical machines
anyhow, and one interface towards the rest of HECnet, in which case a
Multinet link is just as good as anything else, and already is known to
work, and can be done with the equipment he has at hand, if he just
installs VMS Multinet.
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
2541
days inactive
2542
days old
4 comments
3 participants
participants (3)
-
bqt＠softjar.se -
nf6x＠nf6x.net -
supratim＠riseup.net