14 Jan
2016
14 Jan
'16
1:43 a.m.
Ok. I now have my Multinet circuits set up on MIM. Only UDP at the
moment, but who would like to peer with me, and reduce the size of the
bridge?
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
5:31 a.m.
This past Sunday, Johnny and I spent a fair amount of time looking at
circuit costs (and performance) between SG1:: and JOCKE:: while testing
his new Multinet-tunneling code. The findings were a bit strange to say
the least. At the moment, the LAN circuit costs here are set to "4" to
reflect what the VMS machines set their network interfaces to. It seems
that RSX sets costs to "3". Why are they different? Who knows!
The Multinet circuit costs coming out of here are "4" or less depending
on various factors. They include but are not limited to: circuit
speeds, number of links to a leaf node (site), and types of links. I
treat this site as a hub because it services so many leaf nodes
(sites). I treat all other sites (except LEGATO:: and MIM::) as leaf
nodes (sites). LEGATO:: and MIM:: are treated as hubs (or peers). In a
2 weeks I will be back from vacation and will be prepared to look
further into possible circuit cost changes.
Bandwidth at this site (either coming or going) is no longer a problem.
Stay tuned... :-)
-Steve
On 1/13/2016 20:52, Peter Lothberg wrote:
192.108.200.211 -- 130.238.19.212 Decnet COST 30
5:05 p.m.
On Jan 13, 2016, at 11:31 PM, Steve Davidson <steve
at davidson.net> wrote:
This past Sunday, Johnny and I spent a fair amount of time looking at circuit costs (and
performance) between SG1:: and JOCKE:: while testing his new Multinet-tunneling code. The
findings were a bit strange to say the least. At the moment, the LAN circuit costs here
are set to "4" to reflect what the VMS machines set their network interfaces to.
It seems that RSX sets costs to "3". Why are they different? Who knows!
The values are somewhat arbitrary; it doesn't really matter what scheme you use but if
you are inconsistent the routing may be surprising.
The routing spec has a suggested algorithm (100,000/line speed) which may have made sense
in the old days but for modern networks isn't terribly useful.
paul
9:02 p.m.
The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
Maybe performance is not the most important factor in Hecnet.?
-P
Ps: In parts of the big internet, the metric for a link reflects it's
delay (remember speed of light in glass is not that great...).
9:29 p.m.
On Jan 14, 2016, at 3:02 PM, Peter Lothberg <roll
at Stupi.SE> wrote:
If costs are the same at both ends of a link, that will certainly help. Then again, it is
quite possible for two paths to have equal cost, and if so, DECnet implementations will
pick one of the two, in a way that is not specified.
paul
The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
9:36 p.m.
On 2016-01-14 21:29, Paul_Koning at Dell.com wrote:
Yes. But I think that Peter is actually advocating that cost for
ethernet should be larger than cost for Multinet link at all nodes, in
order to most of the time decide to favor the multinet links.
Ie. Not have a situation where node a uses the multinet link to talk to
node b, and b uses ethernet (bridge) to send responses back to a.
DECnet works just fine with such different paths, though. So it's just a
question of - will the multinet links give better performance than
ethernet and the bridge?
Both ends could have equal or different costs for the links. As long as
the relative order of costs between the links are the same, they should
then both favor the multinet link. However, it can become more
interesting when there are multiple paths, and multiple hops, as the
costs are the sum of the cost of all hops, meaning that potentially,
what cost other people put on their links can affect how your forwarding
matrix looks like.
Johnny
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
If costs are the same at both ends of a link, that will certainly help. Then again, it
is quite possible for two paths to have equal cost, and if so, DECnet implementations will
pick one of the two, in a way that is not specified. The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
9:38 p.m.
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
If costs are the same at both ends of a link, that will certainly
help. Then again, it is quite possible for two paths to have equal
cost, and if so, DECnet implementations will pick one of the two, in
a way that is not specified.
paul The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
10:05 p.m.
On 2016-01-14 21:38, Peter Lothberg wrote:
If all links in HECNet where point-to-point, with the same metric on
both sides, it will most likely be almost *perfect* by itself.
The complex movie is when they *THINK* they are all on the same
ethernet with metric 1.....
Well, in all honesty, default cost for ethernet links in VMS is 4, and
in RSX is 3...
So, if you want to favor a different link, set the cost to less.
But you are blindly assuming that Multinet (or other) point-to-point
links are better. That one I still do not see. There are definitely
cases where it can be worse.
The worst thing about the bridge is, as I wrote in another mail, is when
you are on an ethernet segment, and you want to talk to a different
area, which have several area routers on that same ethernet segment you
are on, in which case you might end up going through pretty bad hopping.
Johnny
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
If costs are the same at both ends of a link, that will certainly
help. Then again, it is quite possible for two paths to have equal
cost, and if so, DECnet implementations will pick one of the two, in
a way that is not specified.
paul The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny... 
10:26 p.m.
Johnny,?
When the area routers in the other area are on the same LAN then the bridge w?ill only be
involved if there is another area router in that other area on the remote side of the
bridge program.
And will (very likely) slow down communications.
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?
Hans
Verzonden?vanaf?mijn?BlackBerry?10-smartphone.
? Origineel bericht ?
Van: Johnny Billquist
Verzonden: donderdag 14 januari 2016 22:06
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet peerings...?
On 2016-01-14 21:38, Peter Lothberg wrote:
If all links in HECNet where point-to-point, with the same metric on
both sides, it will most likely be almost *perfect* by itself.
The complex movie is when they *THINK* they are all on the same
ethernet with metric 1.....
Well, in all honesty, default cost for ethernet links in VMS is 4, and
in RSX is 3...
So, if you want to favor a different link, set the cost to less.
But you are blindly assuming that Multinet (or other) point-to-point
links are better. That one I still do not see. There are definitely
cases where it can be worse.
The worst thing about the bridge is, as I wrote in another mail, is when
you are on an ethernet segment, and you want to talk to a different
area, which have several area routers on that same ethernet segment you
are on, in which case you might end up going through pretty bad hopping.
Johnny
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
If costs are the same at both ends of a link, that will certainly
help. Then again, it is quite possible for two paths to have equal
cost, and if so, DECnet implementations will pick one of the two, in
a way that is not specified.
paul The values are somewhat arbitrary; it doesn't
really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
10:35 p.m.
On 2016-01-14 22:26, hvlems at zonnet.nl wrote:
Johnny,
When the area routers in the other area are on the same LAN then the bridge w?ill only be
involved if there is another area router in that other area on the remote side of the
bridge program.
And will (very likely) slow down communications.
The bridge have no clue about areas at all. No more than a physical
ethernet cable would. There don't have to be area routers on any side.
But if there are, they are no different from any other ethernet node.
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.
(I hope the explanation makes sense, otherwise I can try and explain it
more. I tried doing this many years ago, and ended up realized it cannot
be done.)
Johnny
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Johnny Billquist
Verzonden: donderdag 14 januari 2016 22:06
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet peerings...?
On 2016-01-14 21:38, Peter Lothberg wrote:
If all links in HECNet where point-to-point, with the same metric on
both sides, it will most likely be almost *perfect* by itself.
The complex movie is when they *THINK* they are all on the same
ethernet with metric 1.....
Well, in all honesty, default cost for ethernet links in VMS is 4, and
in RSX is 3...
So, if you want to favor a different link, set the cost to less.
But you are blindly assuming that Multinet (or other) point-to-point
links are better. That one I still do not see. There are definitely
cases where it can be worse.
The worst thing about the bridge is, as I wrote in another mail, is when
you are on an ethernet segment, and you want to talk to a different
area, which have several area routers on that same ethernet segment you
are on, in which case you might end up going through pretty bad hopping.
Johnny
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
> The values are somewhat arbitrary; it doesn't really matter what
> scheme you use but if you are inconsistent the routing may be
> surprising.
>
> The routing spec has a suggested algorithm (100,000/line speed)
> which may have made sense in the old days but for modern networks
> isn't terribly useful.
> paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
If costs are the same at both ends of a link, that will certainly
help. Then again, it is quite possible for two paths to have equal
cost, and if so, DECnet implementations will pick one of the two, in
a way that is not specified.
paul
10:40 p.m.
Yes, I'd forgotten that endnodes can do that on a local LAN. Provided there's no
router in that area, be it level 1 or level 2.
Verzonden?vanaf?mijn?BlackBerry?10-smartphone.
? Origineel bericht ?
Van: Johnny Billquist
Verzonden: donderdag 14 januari 2016 22:35
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet peerings...?
On 2016-01-14 22:26, hvlems at zonnet.nl wrote:
Johnny,
When the area routers in the other area are on the same LAN then the bridge w?ill only be
involved if there is another area router in that other area on the remote side of the
bridge program.
And will (very likely) slow down communications.
The bridge have no clue about areas at all. No more than a physical
ethernet cable would. There don't have to be area routers on any side.
But if there are, they are no different from any other ethernet node.
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.
(I hope the explanation makes sense, otherwise I can try and explain it
more. I tried doing this many years ago, and ended up realized it cannot
be done.)
Johnny
Hans
Verzonden vanaf mijn BlackBerry 10-smartphone.
Origineel bericht
Van: Johnny Billquist
Verzonden: donderdag 14 januari 2016 22:06
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Multinet peerings...?
On 2016-01-14 21:38, Peter Lothberg wrote:
If all links in HECNet where point-to-point, with the same metric on
both sides, it will most likely be almost *perfect* by itself.
The complex movie is when they *THINK* they are all on the same
ethernet with metric 1.....
Well, in all honesty, default cost for ethernet links in VMS is 4, and
in RSX is 3...
So, if you want to favor a different link, set the cost to less.
But you are blindly assuming that Multinet (or other) point-to-point
links are better. That one I still do not see. There are definitely
cases where it can be worse.
The worst thing about the bridge is, as I wrote in another mail, is when
you are on an ethernet segment, and you want to talk to a different
area, which have several area routers on that same ethernet segment you
are on, in which case you might end up going through pretty bad hopping.
Johnny
On Jan 14, 2016, at 3:02 PM, Peter Lothberg
<roll at Stupi.SE> wrote:
> The values are somewhat arbitrary; it doesn't really matter what
> scheme you use but if you are inconsistent the routing may be
> surprising.
>
> The routing spec has a suggested algorithm (100,000/line speed)
> which may have made sense in the old days but for modern networks
> isn't terribly useful.
> paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
If costs are the same at both ends of a link, that will certainly
help. Then again, it is quite possible for two paths to have equal
cost, and if so, DECnet implementations will pick one of the two, in
a way that is not specified.
paul
15 Jan
15 Jan
2:03 a.m.
On Jan 14, 2016, at 4:40 PM, hvlems at zonnet.nl
wrote:
...
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).
paul
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. 
3:25 a.m.
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?
-brian
On Jan 14, 2016, at 4:40 PM, hvlems at zonnet.nl
wrote:
...
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). 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.
3:42 a.m.
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 || 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:
...
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). 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.
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).
4:01 a.m.
On 2016-01-15 03:55, Brian Hechinger wrote:
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.
Right. As long as they have something they can connect with.
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?
Yes. Totally. But a couple of years ago, your options were really
limited no matter who you were. Multinet VMS, Cisco GRE, and that was
about it. If people were running something else, you had no options at
all. And that is still true for some people. However, with the pything
decnet router and so on, they now also have an option.
My point is essentially that for many, ethernet was the only reasonable
option for a long time, so the bridge made sense. And it still does for
some. However, where we can run something else, we should. Having a
larger ethernet segment that covers the whole world is not really a
great solution. :-)
Johnny
-brian
--
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
On Jan 14, 2016, at 9:42 PM, Johnny Billquist
<bqt at softjar.se
<mailto: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
<mailto:Paul_Koning at dell.com>> <Paul_Koning at Dell.com
<mailto:Paul_Koning at dell.com>> wrote:
> On Jan 14, 2016, at 4:40 PM, hvlems at zonnet.nl
> <mailto: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? 
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).
4:11 a.m.
On 2016-01-15 04:05, Mark Pizzolato wrote:
On Thursday, January 14, 2016 at 6:42 PM, Johnny
Billquist wrote:
Well, I'm thinking actual, physical machines, and not emulated ones... :-)
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
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.
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.
> 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? 
16 Jan
16 Jan
midnight
-----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:
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
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... :-)
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
2:14 a.m.
On Jan 15, 2016, at 6:00 PM, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
...
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).
Sounds great, but where would you find a synchronous interface for a PC?
paul
9:50 a.m.
-----Original Message-----
From: owner-hecnet at update.uu.se [mailto:owner-hecnet at update.uu.se]
On Behalf Of Paul_Koning at Dell.com
Sent: 16 January 2016 01:14
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet peerings...?
> On Jan 15, 2016, at 6:00 PM, Robert Jarratt
<robert.jarratt at
ntlworld.com>
wrote:
>
> ...
> 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).
Sounds great, but where would you find a synchronous interface for a PC?
paul
I remember looking for some once and I am sure I found them. They aren't
cheap though.
Regards
Rob
12:03 a.m.
-----Original Message-----
From: Robert Jarratt [mailto:robert.jarratt at ntlworld.com]
Sent: 15 January 2016 23:00
To: 'hecnet at update.uu.se' <hecnet at update.uu.se>
Subject: RE: [HECnet] Multinet peerings...?
<SNIP>
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).
Oh! And just for fun, I am attempting to see if I can port it to VAXELN.
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
15 Jan
15 Jan
11:59 p.m.
-----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:
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
On 2016-01-15 03:25, Brian Hechinger wrote:
until this protocol mechanism was added.
> 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 >>
>> 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
- Mark
6:42 p.m.
Johnny,
When I checkin this evening I will add the link to MIM::. Which IP address do do want me
to use and do you want me disconnect the bridge at the same time?
-Steve
On Jan 14, 2016, at 21:42, 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 || 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).
6:46 p.m.
Johnny,
Do you want the JOCKE:: link to remain in place after adding the MIM:: link?
-Steve
On Jan 14, 2016, at 21:42, 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 || 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).
16 Jan
16 Jan
11:10 a.m.
Steve, did you get my mail where I said the peering is
udp:mim.update.uu.se:700 and that we don't need the link to JOCKE:: anymore?
Johnny
On 2016-01-15 18:46, Steve Davidson wrote:
Johnny,
Do you want the JOCKE:: link to remain in place after adding the MIM:: link?
-Steve
> On Jan 14, 2016, at 21:42, Johnny Billquist <bqt at softjar.se> 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.
>
> 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 || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
--
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
15 Jan
15 Jan
11:53 p.m.
-----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 02:42
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet peerings...?
On 2016-01-15 03:25, Brian Hechinger wrote:
<SNIP>
> 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?
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 || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
14 Jan
14 Jan
9:32 p.m.
On 2016-01-14 21:02, Peter Lothberg wrote:
What I realized when I was working with Steve this Sunday was that in
many cases, the biggest performance hit comes if you have several area
routers and use the bridge. For most other purposes, as long as you stay
consistent, you should be good. The bridge is actually not a performance
problem itself, as such.
However, anyone talking to MIM will suffer, and will continue to suffer,
as long as they use the bridge.
Bridge performance should be equal to the Multinet links in general.
And, of course, if you are communicating between nodes in the same area,
the bridge should even be better than the Multinet links.
The situation where you loose is when you go from one area to another,
and you have several area routers on the same ethernet segment you
yourself are on. In this situation, DECnet will pick the highest
numbered node in the remote area, and use that as the next hop to the
area. Now, in HECnet, area 1 have three area routers. MIM, PONDUS and
JOCKE. While most people would like to talk to MIM, if they talk with
area 1, they will always be routed through JOCKE or PONDUS, since those
two machines have higher numbers.
In the past, only PONDUS was the additional area router, and PONDUS is a
real PDP-11/93. Not the fastest machine around. In addition, PONDUS and
JOCKE are located in Switzerland, while MIM is in Sweden.
So, anyone outside of area 1 trying to talk to MIM over the bridge would
send the packets to PONDUS, in Switzerland, and PONDUS would then send
the packets back out on the same bridge to get to MIM. Responses back
would go direct, as MIM would, on its own, know where to route the
packets returned.
But this is pretty suboptimal. And there isn't much we can do about it.
That is the way DECnet works. It would be wonderful to be able to point
to MIM as being the primary area router for area 1, but DECnet only have
this concept for intra-area deignated routers on an ethernet. That's
where the router priority is used. But for areas, no such thing exists.
Obviously, in the old days, you would not expect people on the same
ethernet segment to actually be in different areas, so it was probably
never thought much about. But that is exactly the scenario the bridge
creates.
And, obviously, the solution is to actually have ptp-links between areas
instead. And I'm working on it. However, I have hit some obscure bug in
my code related to multiprocessor RSX internals, which I'm still trying
to figure out. Once that is solved, I'll start actually getting these
links running on mim, and people in other areas can optionally stop
using the bridge to area 1, which will improve life.
As for cost tweaking for other areas (areas without multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
Johnny
The values are
somewhat arbitrary; it doesn't really matter what
scheme you use but if you are inconsistent the routing may be
surprising.
The routing spec has a suggested algorithm (100,000/line speed)
which may have made sense in the old days but for modern networks
isn't terribly useful.
paul
What I wanted to get to was a scenario where traffic was symetric
between two nodes, eg, use the same links from a-b as b-a, it makes it
much easier to understand what's wrong when things behave funny...
Maybe performance is not the most important factor in Hecnet.?
-P
Ps: In parts of the big internet, the metric for a link reflects it's
delay (remember speed of light in glass is not that great...).
9:50 p.m.
As for cost tweaking for other areas (areas without
multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
If nodes that are both on the bridge-ethernet and also acts as
multinet hubs had a resonable high metric on their ethernets...
--P
9:54 p.m.
Something I?ve been thinking about doing is getting a ?router? box setup that talks to
local lan, multinet and an ethernet segment dedicated to the bridge.
That would require I actually setup a box though. :)
-brian
On Jan 14, 2016, at 3:50 PM, Peter Lothberg <roll
at Stupi.SE> wrote:
As for cost tweaking for other areas (areas
without multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
If nodes that are both on the bridge-ethernet and also acts as
multinet hubs had a resonable high metric on their ethernets...
--P
10 p.m.
On Jan 14, 2016, at 3:54 PM, Brian Hechinger <wonko
at 4amlunch.net> wrote:
Something I?ve been thinking about doing is getting a ?router? box setup that talks to
local lan, multinet and an ethernet segment dedicated to the bridge.
That would require I actually setup a box though. :)
DECnet/Python can't do this just yet, but it's on my to-do list. That will allow
you to create setups like that without requiring boxes.
paul
10:01 p.m.
Ooooohhhh, I look forward to this!
-brian
On Jan 14, 2016, at 4:00 PM, <Paul_Koning at
Dell.com> <Paul_Koning at Dell.com> wrote:
On Jan 14, 2016, at 3:54 PM, Brian Hechinger
<wonko at 4amlunch.net> wrote:
Something I?ve been thinking about doing is getting a ?router? box setup that talks to
local lan, multinet and an ethernet segment dedicated to the bridge.
That would require I actually setup a box though. :)
DECnet/Python can't do this just yet, but it's on my to-do list. That will allow
you to create setups like that without requiring boxes.
paul
15 Jan
15 Jan
12:20 a.m.
-----Original Message-----
From: owner-hecnet at update.uu.se [mailto:owner-hecnet at update.uu.se]
On Behalf Of Paul_Koning at Dell.com
Sent: 14 January 2016 21:01
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet peerings...?
My user mode router can talk to a remote instance of the bridge and to a local LAN, but it
doesn't do multinet.
Regards
Rob
On Jan 14, 2016, at 3:54 PM, Brian Hechinger
<wonko at 4amlunch.net>
wrote:
Something I?ve been thinking about doing is getting a ?router? box setup
that
talks to local lan, multinet and an ethernet segment dedicated to the
bridge.
That would require I actually setup a box though. :)
DECnet/Python can't do this just yet, but it's on my to-do list. That will
allow
you to create setups like that without requiring boxes.
paul
14 Jan
14 Jan
10:11 p.m.
On 2016-01-14 21:50, Peter Lothberg wrote:
Could you explain why you think this is better?
Now, I just did realize one possible reason, and that is since all
bridges use Update as a hub, the UDP packets run through there, even if
talking between two nodes in the US. That is suboptimal. Now, the bridge
don't have to be setup that way, it's just been the case that people
have decided to use Update as the hub. It would make much more sense to
have a couple of bridge hubs in the US - say one west, and one east.
Have west bridge connect to east bridge, and have east bridge connect to
Update. And then people connect to the hub in reasonable vicinity.
But the bridge as such, are not worse than the multinet links. If your
only reason is because of the current topology of the bridge itself,
then yes, for some it will be a win to favor the multinet links. Mostly
people in the US. For others, it might definitely be worse.
It all depends. It's not just a simple case of one size fits all.
Johnny
As for cost
tweaking for other areas (areas without multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
If nodes that are both on the bridge-ethernet and also acts as
multinet hubs had a resonable high metric on their ethernets...
10:32 p.m.
On Jan 14, 2016, at 4:11 PM, Johnny Billquist <bqt
at softjar.se> wrote:
On 2016-01-14 21:50, Peter Lothberg wrote:
Could you explain why you think this is better?
Now, I just did realize one possible reason, and that is since all bridges use Update as
a hub, the UDP packets run through there, even if talking between two nodes in the US.
That is suboptimal. Now, the bridge don't have to be setup that way, it's just
been the case that people have decided to use Update as the hub. It would make much more
sense to have a couple of bridge hubs in the US - say one west, and one east. Have west
bridge connect to east bridge, and have east bridge connect to Update. And then people
connect to the hub in reasonable vicinity.
But the bridge as such, are not worse than the multinet links. If your only reason is
because of the current topology of the bridge itself, then yes, for some it will be a win
to favor the multinet links. Mostly people in the US. For others, it might definitely be
worse.
It sounds like you're reinventing routing... but if you want routing, why not have the
routing layer do it?
The bridge is a nice mechanism, and a very simple way to do straightforward things. But
if you run into situations where it isn't the right tool, having the DECnet routing
mechanisms solve it for you is probably the simplest answer.
paul
As for
cost tweaking for other areas (areas without multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
If nodes that are both on the bridge-ethernet and also acts as
multinet hubs had a resonable high metric on their ethernets...
10:38 p.m.
On 2016-01-14 22:32, Paul_Koning at Dell.com wrote:
Well, kindof. It's actually more of - if you want to run a wire between
build A and B, it makes sense to draw the wire directly between A and B,
without crossing the Atlantic twice, even though that also works...
With virtual cables, doing such cabling is way too easy...
On Jan 14, 2016, at 4:11 PM, Johnny Billquist
<bqt at softjar.se> wrote:
On 2016-01-14 21:50, Peter Lothberg wrote:
Could you explain why you think this is better?
Now, I just did realize one possible reason, and that is since all bridges use Update as
a hub, the UDP packets run through there, even if talking between two nodes in the US.
That is suboptimal. Now, the bridge don't have to be setup that way, it's just
been the case that people have decided to use Update as the hub. It would make much more
sense to have a couple of bridge hubs in the US - say one west, and one east. Have west
bridge connect to east bridge, and have east bridge connect to Update. And then people
connect to the hub in reasonable vicinity.
But the bridge as such, are not worse than the multinet links. If your only reason is
because of the current topology of the bridge itself, then yes, for some it will be a win
to favor the multinet links. Mostly people in the US. For others, it might definitely be
worse.
It sounds like you're reinventing routing... but if you want routing, why not have
the routing layer do it? As for
cost tweaking for other areas (areas without multiple area
routers that is), I do not believe that tweaking the costs to favor
Multinet links will improve life. But I'm interested to hear theories
that claims otherwise, and we can try figuring out if they make sense.
If nodes that are both on the bridge-ethernet and also acts as
multinet hubs had a resonable high metric on their ethernets... The bridge is a nice mechanism, and a very simple way
to do straightforward things. But if you run into situations where it isn't the right
tool, having the DECnet routing mechanisms solve it for you is probably the simplest
answer.
Sortof. See above...
Johnny
9:59 p.m.
On Jan 14, 2016, at 3:32 PM, Johnny Billquist <bqt
at softjar.se> wrote:
...
The situation where you loose is when you go from one area to another, and you have
several area routers on the same ethernet segment you yourself are on. In this situation,
DECnet will pick the highest numbered node in the remote area,
Yes, and indeed that is the tiebreaking rule for equal cost paths in general. I had
forgotten that. It would not surprise me if that particular detail is not always
implemented according to the spec.
paul
10:16 p.m.
On 2016-01-14 21:59, Paul_Koning at Dell.com wrote:
We observed VMS and RSX, and they both seemed to act as expected.
However, it is obviously not ideal under these circumstances. But as
there are only one path (ethernet), this tiebreaker is all there is.
Some kind of router priority value, independent of the node number,
would have been useful. But that's life.
Johnny
On Jan 14, 2016, at 3:32 PM, Johnny Billquist
<bqt at softjar.se> wrote:
...
The situation where you loose is when you go from one area to another, and you have
several area routers on the same ethernet segment you yourself are on. In this situation,
DECnet will pick the highest numbered node in the remote area,
Yes, and indeed that is the tiebreaking rule for equal cost paths in general. I had
forgotten that. It would not surprise me if that particular detail is not always
implemented according to the spec. 
18 Jan
18 Jan
4:07 a.m.
On 14/01/2016 9:52 AM, Peter Lothberg wrote:
192.108.200.211 -- 130.238.19.212 Decnet COST 30
Hi Peter,
My GRE tunnel to you seems to have stopped working at some point. Am I
still in the configuration? My IP has not changed, it is still
120.146.225.243.
Regards, Tim.
3230
days inactive
3234
days old
39 comments
9 participants
participants (9)
-
bqt＠softjar.se -
hvlems＠zonnet.nl -
Mark＠infocomm.com -
Paul_Koning＠Dell.com -
robert.jarratt＠ntlworld.com -
roll＠Stupi.SE -
steve＠davidson.net -
tim＠sneddon.id.au -
wonko＠4amlunch.net