15 Jan
2016
15 Jan
'16
3:55 a.m.
Well, the routers really only need to support ethernet and whatever we make their WAN
links. No one else should care. The only thing this changes for others is which bridge hub
they connect to.
It?s only a small number of people who need to decide on what this WAN link is going to
be. And it doesn?t have to be the same between any two hubs. If you want to use Multinet
to me (for example) and I want to do GRE to Paul that really shouldn?t matter.
Does that makes sense?
-brian
On Jan 14, 2016, at 9:42 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2016-01-15 03:25, Brian Hechinger wrote:
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.
I can now happily add another. I think I found the annoying bug in my Multinet-compatible
DECnet driver for RSX, so now RSX can also haul long links over point-to-point instead of
having to rely on the bridge.
First link, between MIM and LEGATO is up, and looking stable.
More coming, I hope. Steve, how about SG1? ;-)
Peter, would you like a link or two between somewhere at your end and MIM as well? Maybe
less useful, since we already have DIMMA that does the same.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder
books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jan 14, 2016, at 8:03 PM, <Paul_Koning at
Dell.com> <Paul_Koning at Dell.com> 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? 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).