10 Sep
2022
10 Sep
'22
3:37 p.m.
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
10 Sep
10 Sep
4:50 p.m.
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into the dark
area of cisco routes I don't have a direct route to A1 anymore. However I have routes
to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's a
great visualization of all the nerds that like to keep ancient software up and running. If
we could find a way to incorporate the dark routes of gre tunnels between cisco/ios boxes
that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se> följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
5:07 p.m.
Tomas and others....
The only way to get DECnet information out of a cisco box, not
using the cli is to talk SNMP over IP (v4/v6) to it.
This leaves us with three problems:
- How to map a DECnet node number in to an IP address
- Access control and enabling SNMP RO to some remote addresses
- Writing the SW to integrate this in to Pauls tool (or some other tool)
-P
Personally I think we only need to optimize HECnet for reachability
and some redundancy.. At the speed the old computers are running, the
link delay might not be the first order problem.
----- Original Message -----
From: "Tomas Prybil"
<tomas(a)prybil.se>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 10:50:41 AM
Subject: [HECnet] Re: An example of non-optimal setup
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into
the dark area of cisco routes I don't have a direct route to A1 anymore.
However I have routes to A12, A27, A31, A59 and A61 (A22 fell off some time
ago) They are all weighted in accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked
into I agree. Could be a hiccup since the relocation from Uppsala to Stockholm.
I don't know.
Paul has a fantastic tool that describes routes between Areas around the globe.
It's a great visualization of all the nerds that like to keep ancient software
up and running. If we could find a way to incorporate the dark routes of gre
tunnels between cisco/ios boxes that would very much help to show where we
could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se> följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
6:59 p.m.
On Sep 10, 2022, at 11:07 AM, Peter Lothberg
<roll(a)stupi.com> wrote:
Tomas and others....
The only way to get DECnet information out of a cisco box, not
using the cli is to talk SNMP over IP (v4/v6) to it.
This leaves us with three problems:
- How to map a DECnet node number in to an IP address
That would require a table, listing any Cisco routers (or equivalent). Or, if the
neighbor is PyDECnet, I could add some implementation-specific attributes to the circuit
to show the circuit config parameters. Those aren't shown anywhere right now, but it
seems reasonable to make that visible. It would supply the other end's IP address,
unless the circuit and the SNMP daemon are at different addresses. (Is that possible with
Cisco?)
- Access control and enabling SNMP RO to some remote
addresses
Or just opening read to everyone; I don't know of a good reason to disallow that.
- Writing the SW to integrate this in to Pauls tool
(or some other tool)
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound so I
can't query anyone's MIB. The solution would be to build an SNMP proxy, which
would be easy enough, and install that on some helpful server.
A random thought: I wonder if it would be interesting for PyDECnet to implement the DECnet
MIB.
paul
7:09 p.m.
On September 10, 2022 12:59:37 PM Paul Koning <paulkoning(a)comcast.net> wrote:
Wow. Comcast does no such brain-damaged BS here. Is this a "home" connection
or something?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
- Writing the
SW to integrate this in to Pauls tool (or some other tool)
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound so I
can't query anyone's MIB. The solution would be to build an SNMP proxy, which
would be easy enough, and install that on some helpful server.
7:32 p.m.
On Sep 10, 2022, at 1:09 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On September 10, 2022 12:59:37 PM Paul Koning <paulkoning(a)comcast.net> wrote:
Wow. Comcast does no such brain-damaged BS here. Is this a "home" connection
or something?
Yes. I think "business" connections are not so defective, but the policy makes
no sense for home users either.
paul
- Writing
the SW to integrate this in to Pauls tool (or some other tool)
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound so I
can't query anyone's MIB. The solution would be to build an SNMP proxy, which
would be easy enough, and install that on some helpful server. 
8:13 p.m.
Comcast Business is practically a completely different company for all intents and
purposes. They have completely reasonable policies and a tech support staff who know how
stuff works rather than reading from a script.
Unfortunately it's really expensive.
As far as melding Cisco into the rest of things I've been thinking about rewriting the
tunnel manager. As it already talks SNMP to the routers i can leverage that. I can then
provide any info needed and we can do so without exposing SNMP to the internet. I was
thinking in the rewrite to use an agent based system so you would run one on your local
network.
I'll add this to the list of things i want to do. Then i need to wrap up a couple
other personal projects só o have time up dedicate to the rewrite.
-brian
On Sep 10, 2022, 18:33 +0100, Paul Koning <paulkoning(a)comcast.net>et>, wrote:
On Sep 10, 2022, at 1:09 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On September 10, 2022 12:59:37 PM Paul Koning <paulkoning(a)comcast.net> wrote:
Wow. Comcast does no such brain-damaged BS here. Is this a "home" connection or
something?
Yes. I think "business" connections are not so defective, but the policy makes
no sense for home users either.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se - Writing
the SW to integrate this in to Pauls tool (or some other tool)
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound so I
can't query anyone's MIB. The solution would be to build an SNMP proxy, which
would be easy enough, and install that on some helpful server.
11 Sep
11 Sep
3:03 a.m.
On 9/10/22 13:32, Paul Koning wrote:
Wow. Comcast does no such brain-damaged BS here. Is this a "home" connection
or something?
Yes. I think "business" connections are not so defective, but the policy makes
no sense for home users either.
Yeah, the Comcast "home" offerings are web browser connections, not
Internet connections. Life's too short for that BS.
I'm happy to assist with proxying etc from here.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
- Writing the
SW to integrate this in to Pauls tool (or some other tool)
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound so I
can't query anyone's MIB. The solution would be to build an SNMP proxy, which
would be easy enough, and install that on some helpful server. 
10 Sep
10 Sep
8:38 p.m.
I know. Sigh...
Many non-commercial offerings from ISP's have some form of port
limitations that are difficult to know, a priori. That is, until you
bump into them. SMTP comes to mind for Verizon (or maybe it was Optimum
Online). TOMMYT:: sent out-going SMTP for years until it couldn't. I
used that to email myself alerts from Batch. Now? Fuggetabout it.
Of course, when I whined about the outgoing SMTP block, I was promptly
offered a commercial account... These cost more then the residential
offerings, sometimes far more if you are looking to get equivalent
performance. Really, the residential offerings seem largely geared
towards entertainment; that is, watching Netflix and YouTube. Anything
else is bring your wallet.
Standard SNMP can be a security issue. Even if you are using it only to
read values, it constitutes an attack surface from which you can extract
information to potentially vector an exploit. I would imagine that
another thing that could be done would be to tunnel it over ssh for
point to point solutions.
------------------------------------------------------------------------
On 9/10/22 12:59 PM, Paul Koning wrote:
The problem I ran into is that Comcast has a mental problem, they
filter SNMP traffic outbound so I can't query anyone's MIB.
11 Sep
11 Sep
12:02 p.m.
Sorry if this is what you were already alluding to - but since Comcast blocks SNMP, you
could implement the SNMP proxy into PyDECnet and make it an opt-in feature.
I would have no issues with you relaying SNMP requests via my PyDECnet instance, and I
suspect others would be fine with it as well.
Cheers, Wiz!!
-----Original Message-----
From: Paul Koning <paulkoning(a)comcast.net>
Sent: Sunday, 11 September 2022 2:59 AM
To: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: An example of non-optimal setup
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound
so I can't query anyone's MIB. The solution would be to build an SNMP
proxy, which would be easy enough, and install that on some helpful server.
A random thought: I wonder if it would be interesting for PyDECnet to
implement the DECnet MIB.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
12:25 p.m.
I'd second that,I am fortunate to have an unfiltered connection.
Cheers
Mark
On 11/09/2022 11:02, David Moylan wrote:
Sorry if this is what you were already alluding to -
but since Comcast blocks SNMP, you could implement the SNMP proxy into PyDECnet and make
it an opt-in feature.
I would have no issues with you relaying SNMP requests via my PyDECnet instance, and I
suspect others would be fine with it as well.
Cheers, Wiz!!
-----Original Message-----
From: Paul Koning <paulkoning(a)comcast.net>
Sent: Sunday, 11 September 2022 2:59 AM
To: HECnet <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: An example of non-optimal setup
I made a stab at that a while ago; it isn't all that difficult. The problem I ran
into is that Comcast has a mental problem, they filter SNMP traffic outbound
so I can't query anyone's MIB. The solution would be to build an SNMP
proxy, which would be easy enough, and install that on some helpful server.
A random thought: I wonder if it would be interesting for PyDECnet to
implement the DECnet MIB.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10 Sep
10 Sep
5:18 p.m.
If you are running RSX, another tool that can be used to quickly determine your routing
node’s connectivity to other areas is NTD. NTD is a bit like RMD in that normally it is a
live screen that updates every second with new info. Also, like the NCP TELL node command
NTD node displays info for a remote node. It has several screens that can be displayed
showing various types of info like what tasks are connected to DECnet. The one I’d like to
point out is the Area display page. To get a copy of the screen for pasting into an email
( with out the escape sequences for VT100 graphics ) I set the terminal type to a LA120
hard copy:
SET /LA120=TI:
NTD CBVRP3,/PAGE=A
10-SEP-2022 10:06:49 Node: CBVRP3(30.15) CBVRP3 RASPBERRYPI
RSX11M+ V4.6
RSX-11M-Plus, Area Routing Node, DECnet V4.6
Area Circuit Hop/Cst Next Node Area Circuit Hop/Cst Next Node
1 IP-0-2 1/6 ANKE ( 1.1023)
2 IP-0-3 2/13 PYRTR (31.3)
5 IP-0-2 2/11 ANKE ( 1.1023)
9 IP-0-4 3/17 PYTHON(41.1)
12 IP-0-4 4/20 PYTHON(41.1)
24 IP-0-2 2/9 ANKE ( 1.1023)
27 IP-0-4 2/12 PYTHON(41.1)
29 IP-0-2 2/10 ANKE ( 1.1023)
31 IP-0-3 1/6 PYRTR (31.3)
33 IP-0-3 2/11 PYRTR (31.3)
34 IP-0-4 3/18 PYTHON(41.1)
35 IP-0-4 3/24 PYTHON(41.1)
38 IP-0-2 4/19 ANKE ( 1.1023)
39 IP-0-3 2/10 PYRTR (31.3)
41 IP-0-4 1/6 PYTHON(41.1)
42 IP-0-4 3/16 PYTHON(41.1)
59 IP-0-4 3/13 PYTHON(41.1)
61 IP-0-4 3/15 PYTHON(41.1)
62 IP-0-2 3/16 ANKE ( 1.1023)
- Total areas: 19-
So from my connections to HECnet the largest number of hops to an area was 4 with a max
cost of 20.
Best Regards,
Mark
On Sep 10, 2022, at 9:50 AM, Tomas Prybil
<tomas(a)prybil.se> wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into the dark
area of cisco routes I don't have a direct route to A1 anymore. However I have routes
to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
5:31 p.m.
Well. You do know that Uppsala have had multinet links along with
bridges for a long time. No need to use the bridge unless there is some
specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore,
but otherwise nothing have changed. We could setup a ptp link on a
moments notice. Sorry for picking you out as my example, but it was such
a simple and obvious example of where we can improve. :-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into the dark
area of cisco routes I don't have a direct route to A1 anymore. However I have routes
to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
5:43 p.m.
Haha the annual cost and Cisco thread is here.
I diligently follow http://mim.update.uu.se/costs.htm as do some others but not all.
Cisco MIBs expose DECnet information easily (I had posted a MIB and IMPRTR will respond to
it).
Guess area 34 needs to adjust costs.
On Sep 10, 2022, at 11:31 AM, Johnny Billquist
<bqt(a)softjar.se> wrote:
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into the dark
area of cisco routes I don't have a direct route to A1 anymore. However I have routes
to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
7:06 p.m.
Sorry to bother all with the details. We might move the discussion on A34 off the list.
Well the Internet changes obviously, thx for pointing that out Supratim!
Costs are updated on my links and hopefully solves a bit.
I would be more than happy to allow snmp read from specific hosts. (As the ios image is
old and quite possibly has a few CVEs to be poked at)
Johnny, Inga problem =|-;)
BR
/t
Från: Supratim Sanyal <supratim(a)riseup.net>
Svara till: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Datum: lördag 10 september 2022 17:43
Till: The Hobbyist DECnet mailing list <hecnet(a)lists.dfupdate.se>
Ämne: [HECnet] Re: An example of non-optimal setup
Haha the annual cost and Cisco thread is here.
I diligently follow http://mim.update.uu.se/costs.htm as do some others but not all.
Cisco MIBs expose DECnet information easily (I had posted a MIB and IMPRTR will respond to
it).
Guess area 34 needs to adjust costs.
On Sep 10, 2022, at 11:31 AM, Johnny Billquist <bqt(a)softjar.se> wrote:
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm, SWEDEN
Since I went the route of not running a bridged setup to Uppsala and went into the dark
area of cisco routes I don't have a direct route to A1 anymore. However I have routes
to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's a
great visualization of all the nerds that like to keep ancient software up and running. If
we could find a way to incorporate the dark routes of gre tunnels between cisco/ios boxes
that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se> följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________ HECnet mailing list --
hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
8:52 p.m.
From my point of view, Area 34 is now reachable via Washington DC with a cost of 20, where
I have direct connection to Stockholm with cost 4. See att screenshot from my pyDECnet
monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long time.
No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm,
SWEDEN Since I went the route of not running a bridged setup to Uppsala and went into the
dark area of cisco routes I don't have a direct route to A1 anymore. However I have
routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
10:46 p.m.
Curious. Two things would be helpful. One is "show area status" and "show
circuit status" NCP output. The other is the "Routing Layer" ->
"Internals" HTTP monitor page (the whole thing).
I've had some strange things in the past where routes were not recalculated correctly.
If you have V1.0, consider using T1.1, there may be some relevant fixes in it.
paul
On Sep 10, 2022, at 2:52 PM, Wilm Boerhout
<wboerhout(a)gmail.com> wrote:
From my point of view, Area 34 is now reachable via Washington DC with a cost of 20,
where I have direct connection to Stockholm with cost 4. See att screenshot from my
pyDECnet monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm,
SWEDEN Since I went the route of not running a bridged setup to Uppsala and went into the
dark area of cisco routes I don't have a direct route to A1 anymore. However I have
routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<ScreenHunter 270.jpg>_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
11 Sep
11 Sep
3:06 a.m.
To answer Wilm's question. The "problem" with area 34 is that even
though it's physically located there, from the DECnet topology view, it
don't have any connections to anything except places in the US, so
packets to area 34 travel a long way. And therefore the cost is
"correct". If we get some connection from area 34 to somewhere nearer,
that will become the preferred path from Wilm, and the cost will go down.
But first we need to set up some link(s) to area 34 from other places.
How about you set one up, Wilm?
Johnny
On 2022-09-10 22:46, Paul Koning wrote:
Curious. Two things would be helpful. One is
"show area status" and "show circuit status" NCP output. The other is
the "Routing Layer" -> "Internals" HTTP monitor page (the whole
thing).
I've had some strange things in the past where routes were not recalculated
correctly. If you have V1.0, consider using T1.1, there may be some relevant fixes in
it.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Sep 10, 2022, at 2:52 PM, Wilm Boerhout
<wboerhout(a)gmail.com> wrote:
From my point of view, Area 34 is now reachable via Washington DC with a cost of 20,
where I have direct connection to Stockholm with cost 4. See att screenshot from my
pyDECnet monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm,
SWEDEN Since I went the route of not running a bridged setup to Uppsala and went into the
dark area of cisco routes I don't have a direct route to A1 anymore. However I have
routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<ScreenHunter 270.jpg>_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
8:18 a.m.
I sure can.
@Tomas,
Do you have a PyDECnet instance that we can use to connect our area routers? If so, can we
work on this off-list?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Sunday, September 11, 2022 3:06 AM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
To answer Wilm's question. The "problem" with area 34 is that even though
it's physically located there, from the DECnet topology view, it don't have any
connections to anything except places in the US, so packets to area 34 travel a long way.
And therefore the cost is "correct". If we get some connection from area 34 to
somewhere nearer, that will become the preferred path from Wilm, and the cost will go
down.
But first we need to set up some link(s) to area 34 from other places.
How about you set one up, Wilm?
Johnny
On 2022-09-10 22:46, Paul Koning wrote:
Curious. Two things would be helpful. One is
"show area status" and "show circuit status" NCP output. The other is
the "Routing Layer" -> "Internals" HTTP monitor page (the whole
thing).
I've had some strange things in the past where routes were not recalculated
correctly. If you have V1.0, consider using T1.1, there may be some relevant fixes in
it.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
On Sep 10, 2022, at 2:52 PM, Wilm Boerhout
<wboerhout(a)gmail.com> wrote:
From my point of view, Area 34 is now reachable via Washington DC
with a cost of 20, where I have direct connection to Stockholm with
cost 4. See att screenshot from my pyDECnet monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore,
but otherwise nothing have changed. We could setup a ptp link on a
moments notice. Sorry for picking you out as my example, but it was
such a simple and obvious example of where we can improve. :-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of
Stockholm, SWEDEN Since I went the route of not running a bridged setup to Uppsala and
went into the dark area of cisco routes I don't have a direct route to A1 anymore.
However I have routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are
all weighted in accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se <ScreenHunter
270.jpg>_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
10:05 a.m.
Good morning to you all!
No Johnny I (A34) don't only have connections to the US.
I have a connection to SE, AU and also NZ which really what routing is about, to provide
alternative links in the event of links going away or going bad. I also had a connection
to A22, UK, which I will try to get back on line.
The really strange thing is that the ip routing to A59 and A1 here is almost 100 ms!
That’s the really strange part.
Anyway, I would appreciate any invitations on links from this side of the pond, preferably
gre as my network run on a cisco box.
BR
/t
Den 2022-09-11 03:06 skrev "Johnny Billquist" <bqt(a)softjar.se> följande:
To answer Wilm's question. The "problem" with area 34 is that even
though it's physically located there, from the DECnet topology view, it
don't have any connections to anything except places in the US, so
packets to area 34 travel a long way. And therefore the cost is
"correct". If we get some connection from area 34 to somewhere nearer,
that will become the preferred path from Wilm, and the cost will go down.
But first we need to set up some link(s) to area 34 from other places.
How about you set one up, Wilm?
Johnny
On 2022-09-10 22:46, Paul Koning wrote:
Curious. Two things would be helpful. One is
"show area status" and "show circuit status" NCP output. The other is
the "Routing Layer" -> "Internals" HTTP monitor page (the whole
thing).
I've had some strange things in the past where routes were not recalculated
correctly. If you have V1.0, consider using T1.1, there may be some relevant fixes in
it.
paul
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
On Sep 10, 2022, at 2:52 PM, Wilm Boerhout
<wboerhout(a)gmail.com> wrote:
From my point of view, Area 34 is now reachable via Washington DC with a cost of 20,
where I have direct connection to Stockholm with cost 4. See att screenshot from my
pyDECnet monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm,
SWEDEN Since I went the route of not running a bridged setup to Uppsala and went into the
dark area of cisco routes I don't have a direct route to A1 anymore. However I have
routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<ScreenHunter 270.jpg>_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10:51 a.m.
Hmm. I’m behind a provider firewall (home connection), and I can pinhole incoming
connections based on port number only. Does this work for GRE?
Groet,
Wilm
(Verstuurd vanaf mijn telefoon, dus wat korter dan gewoonlijk.)
(Sent from my phone, so a bit more compact than usual)
Op 11 sep. 2022 om 10:05 heeft Tomas Prybil
<tomas(a)prybil.se> het volgende geschreven:
Good morning to you all!
No Johnny I (A34) don't only have connections to the US.
I have a connection to SE, AU and also NZ which really what routing is about, to provide
alternative links in the event of links going away or going bad. I also had a connection
to A22, UK, which I will try to get back on line.
The really strange thing is that the ip routing to A59 and A1 here is almost 100 ms!
That’s the really strange part.
Anyway, I would appreciate any invitations on links from this side of the pond,
preferably gre as my network run on a cisco box.
BR
/t
Den 2022-09-11 03:06 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
To answer Wilm's question. The "problem" with area 34 is that even
though it's physically located there, from the DECnet topology view, it
don't have any connections to anything except places in the US, so
packets to area 34 travel a long way. And therefore the cost is
"correct". If we get some connection from area 34 to somewhere nearer,
that will become the preferred path from Wilm, and the cost will go down.
But first we need to set up some link(s) to area 34 from other places.
How about you set one up, Wilm?
Johnny
On 2022-09-10 22:46, Paul Koning wrote:
Curious. Two things would be helpful. One is "show area status" and
"show circuit status" NCP output. The other is the "Routing Layer"
-> "Internals" HTTP monitor page (the whole thing).
I've had some strange things in the past where routes were not recalculated
correctly. If you have V1.0, consider using T1.1, there may be some relevant fixes in
it.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se On Sep
10, 2022, at 2:52 PM, Wilm Boerhout <wboerhout(a)gmail.com> wrote:
From my point of view, Area 34 is now reachable via Washington DC with a cost of 20,
where I have direct connection to Stockholm with cost 4. See att screenshot from my
pyDECnet monitor
Where does the extra cost come from?
DECnet cannot be wrong, or do we need actual traffic to calculate the proper route?
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Saturday, September 10, 2022 5:31 PM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: An example of non-optimal setup
Well. You do know that Uppsala have had multinet links along with bridges for a long
time. No need to use the bridge unless there is some specific needs.
But now MIM have moved to Stockholm. Technically not Uppsala anymore, but otherwise
nothing have changed. We could setup a ptp link on a moments notice. Sorry for picking you
out as my example, but it was such a simple and obvious example of where we can improve.
:-)
Johnny
On 2022-09-10 16:50, Tomas Prybil wrote:
Hey
I'm the guy running A34 in Båtbyggartorp in the suburbs of Stockholm,
SWEDEN Since I went the route of not running a bridged setup to Uppsala and went into the
dark area of cisco routes I don't have a direct route to A1 anymore. However I have
routes to A12, A27, A31, A59 and A61 (A22 fell off some time ago) They are all weighted in
accordance to Johnnys ping--to-cost per links.
The specific example of inefficient route between A1 and A34 should be looked into I
agree. Could be a hiccup since the relocation from Uppsala to Stockholm. I don't
know.
Paul has a fantastic tool that describes routes between Areas around the globe. It's
a great visualization of all the nerds that like to keep ancient software up and running.
If we could find a way to incorporate the dark routes of gre tunnels between cisco/ios
boxes that would very much help to show where we could be more efficient in routing.
Any ideas on how to move that thread forward?
BR
/t
Den 2022-09-10 15:38 skrev "Johnny Billquist" <bqt(a)softjar.se>
följande:
I thought I'd share an example of a non-optimal setup for people, so
that you can understand a little better what we currently have.
This is from area 1 to area 34. More specifically ANKE to area 34.
Now, physically, ANKE is in Stockholm, Sweden, while A34RTR is in
Båtbyggartorp, Sweden. They are actually not that far from each other,
physically, if you look on a map. Maybe 40 kilometers at the most.
However, in HECnet, it is 3 hops, and a cost of 20.
Now, when ANKE wants to talk to area 34, the next hops are:
PYTHON - New Boston, NH, USA (cost 8)
IMPRTR - Washington DC, USA (cost 4)
and then I *think* it must be A34RTR, since that should be the final
hop, but since both IMPRTR and A34RTR are Cisco boxes, I can't see.
And a guess that the cost of that last hop would be 8.
But clearly, such a roundabout way to talk to such a close node is
kindof silly. :-) We should have reasonable links, in reasonable
directions, and with appropriate costs, so that we don't have things
like this. No good reason to. It's not like we need to pay money to have
physical cables installed between places.
(This must have been such a fun work back in the day when you needed to
actually pay for the physical cables...)
If the link to PYTHON went down, the alternative route would be through
A39RTR(9), PYRTR(2), IMPRTR(4) and then A34RTR. The costs in
parenthesis. (A cost of 2 between A39RTR and PYRTR seems rather cheap,
but what do I know?)
A few suggestions on how to look at things:
If you have a machine that talks NICE, you can examine for both VMS, RSX
and PyDECnet, what the next hop towards an area is. Giving examples on MIM:
.ncp tell anke sho area 34 stat
Area status as of 10-SEP-22 15:34:49
Next
Area State Cost Hops Circuit Node
34 Reachable 20 3 DMC-15 41.1 (PYTHON)
.ncp tell anke sho cir dmc-15 cha
Circuit characteristics as of 10-SEP-22 15:36:02
Circuit = DMC-15
Level one cost = 8
Hello timer = 60, Listen timer = 630
This can then be repeated for node PYTHON and so on. But as noted, when
you get to a Cisco box, you can't do this. Cisco boxes do not speak NICE.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se
<ScreenHunter 270.jpg>_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
10 Sep
10 Sep
8:25 p.m.
Tops-10 and Tops-20 both speak NICE, so you can do something like:
NCP>telL TOMMYT:: shoW knOWN ciRCUITS
NCP>
13:42:02 NCP
Request # 192 Accepted
NCP>
13:42:02 NCP
Request # 192; Show Known Circuits Summary Completed
Circuit State Loopback Adjacent
Name Node
NI-0-0 On 2.522 (VENTI2)
NI-0-0 2.1023 (A2RTR)
One problem for Tops-20 is that it only speaks DECnet over a DN20 (via a
DTE), an NI or a CI. For the CI, you would see those nodes in the
cluster. However, since--by hardware--all CI nodes adjacent, this is
perhaps of limited use. For the NI, you get the the hosts on the
Ethernet, so you can see that TOMMYT:: knows about VENTI::, which is
where I executed the command from. However, this is of limited
utility. Finally, as I recall, the last release of MCB on a DN20 only
spoke Phase III, so I wasn't clear of what utility this might be.
A Tops-10 node appears to be able to have separate connections via a
KDP, viz:
NCP>tell venti:: shoW knOWN ciRCUITS
NCP>
13:42:30 NCP
Request # 194 Accepted
NCP>
13:42:31 NCP
Request # 194; Show Known Circuits Summary Completed
Circuit State Loopback Adjacent
Name Node
KDP-0-0 On 2.99 (SIMILE)
However, I don't know how useful that would be, either as I think the
number of KDP's may be limited, perhaps to two (?) Unfortunately, the
real problem is that neither NICE knows much about areas. It would
appear that this is not implemented. From VENTI2::
NCP>shoW arEA 2
13:43:06 NCP
Request # 188; Show Area Summary Failed, Unrecognized component,
Entity = Area
NCP>tell TOMMYT:: shoW arEA 2
13:40:14 NCP
Request # 189 Accepted
13:40:14 NCP
Request # 189; Show Area Summary Failed, Unrecognized component,
Entity = Area
NCP>tell VENTI:: shoW arEA 2
13:40:46 NCP
Request # 190 Accepted
13:40:46 NCP
Request # 190; Show Area Summary Completed
No Information
I forget what area information Tops-20 knows about. As I recall from
the last time I looked at the Phase IV router code (ROUTER.MAC), it does
handle a Router Hello message, but I think it only looks for its own
area to make adjacency determinations. I can't remember what it does
with other areas, if anything.
In any event, there are two problems with discovering more about this.
The first is that there is no JSYS interface to the router database, so
you'd have to PEEK%/XPEEK% the monitor to get this information. That's
kind of gross and you'd probably have concurrency issues. Second, the
source to the NICE (NML) processor was never released, so even if I did
modify the NODE% JSYS or create an AREA% JSYS to fetch the information,
I couldn't get the goodies to anyone.
I'm not above doing the JSYS work, but writing a NICE from scratch, or
adapting the Phase II source that I have is a fair bit of work. I'm
sure I'd have a lot of fun with that, but I have a number of projects I
need to wind up, first.
------------------------------------------------------------------------
On 9/10/22 9:37 AM, Johnny Billquist wrote:
...
If you have a machine that talks NICE, you can examine for both VMS,
RSX and PyDECnet, what the next hop towards an area is.
11:13 p.m.
A Tops-10 node appears to be able to have separate
connections via a KDP, viz:
It's not a TOPS-10 issue; it's a KS10/2020 limitation because Ethernet is not
supported on that machine. The KDP is actually a combination of one KDP and one or more
DUPs. Each DUP is a single synchronous line interface and you can have up to four. They
can be used for either DECnet or ANF10. I believe that officially DECnet only supported
one DUP line, but in practice you could have more.
But on a KL10, of course, it's the same as for TOPS20 and normally you'd have
the NI20 Ethernet interface. But I'm pretty sure there was a DN-something front end
that supported synchronous DECnet circuits, so I would expect those were possible too.
Bob
11 Sep
11 Sep
12:53 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 17:13, Robert Armstrong wrote:
Ok, so what about some other DECnet connectivity to a KS10? Maybe a
KMC11 or similar, talking to a serial interface on a Cisco?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
A Tops-10 node
appears to be able to have separate connections via a KDP, viz:
It's not a TOPS-10 issue; it's a KS10/2020 limitation because Ethernet is not
supported on that machine. The KDP is actually a combination of one KDP and one or more
DUPs. Each DUP is a single synchronous line interface and you can have up to four. They
can be used for either DECnet or ANF10. I believe that officially DECnet only supported
one DUP line, but in practice you could have more.
1:34 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
There is a way to do T10 IP and ANF on a Ethernet on the KS, but that's
a major hack.. We also had ITS with IP Ethernet support for the 2020.
The KMC/DUP speaks "DDCMP" that is not spoken by a cisco router sync interface.
You need for example to run the sync line from the 2020 to a LSI-11 with
RSX (as you can get help from Johnny with rsx..) and a sync and Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
MRC/Grossman's hack on t20 4.x makes the 2020 run Decnet IV on a sync line,
same gateway as above.
TommyT was complaining that he could not get area info from T10/T20 that's because
it can either be end-node or level-1 router, not level 2 router.
-P
----- Original Message -----
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 6:53:22 PM
Subject: [HECnet] Networking a KS10, was Re: Re: An example of non-optimal setup
Ok, so what about some other DECnet connectivity to a
KS10? Maybe a
KMC11 or similar, talking to a serial interface on a Cisco?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
2:55 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 19:34, Peter Lothberg wrote:
The KMC/DUP speaks "DDCMP" that is not
spoken by a cisco router sync interface.
You need for example to run the sync line from the 2020 to a LSI-11 with
RSX (as you can get help from Johnny with rsx..) and a sync and Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
(I'm an old hand at RSX)
So we could use a PDP-11 with a KMC11 to bridge DECnet over DDCMP to
Ethernet?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
3:08 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 2022-09-11 02:55, Dave McGuire wrote:
On 9/10/22 19:34, Peter Lothberg wrote:
Certainly. If you just have an RSX routing node with both interfaces,
you will have the capability of connecting both sides.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
The KMC/DUP speaks "DDCMP" that is not
spoken by a cisco router sync
interface.
You need for example to run the sync line from the 2020 to a LSI-11 with
RSX (as you can get help from Johnny with rsx..) and a sync and Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
(I'm an old hand at RSX)
So we could use a PDP-11 with a KMC11 to bridge DECnet over DDCMP to
Ethernet?
3:10 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 21:08, Johnny Billquist wrote:
Certainly. If you just have an RSX routing node with both interfaces,
you will have the capability of connecting both sides.
That sounds like an interesting solution. I've never routed/bridged
DECnet in that way.
Of course another interesting option would be for pyDECnet to
implement DDCMP, and let some random RPi or virtual machine bridge the
KS' DECnet to the rest of the world.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The KMC/DUP speaks "DDCMP" that is not
spoken by a cisco router sync
interface.
You need for example to run the sync line from the 2020 to a LSI-11 with
RSX (as you can get help from Johnny with rsx..) and a sync and
Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
(I'm an old hand at RSX)
So we could use a PDP-11 with a KMC11 to bridge DECnet over DDCMP
to Ethernet?
3:14 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 2022-09-11 03:10, Dave McGuire wrote:
On 9/10/22 21:08, Johnny Billquist wrote:
Certainly. If you just have an RSX routing node with both interfaces,
you will have the capability of connecting both sides.
That sounds like an interesting solution. I've never routed/bridged
DECnet in that way.
It's no different than any other DECnet routing. And it's technically
routing we're talking about, and not bridging. Any machine with more
than one circuit active at the same time by definition is a router. If
you configure a machine as an end-node it can only have one active circuit.
The KMC/DUP speaks "DDCMP" that is not
spoken by a cisco router sync
interface.
You need for example to run the sync line from the 2020 to a LSI-11
with
RSX (as you can get help from Johnny with rsx..) and a sync and
Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
(I'm an old hand at RSX)
So we could use a PDP-11 with a KMC11 to bridge DECnet over DDCMP
to Ethernet? Of course another interesting option would be for
pyDECnet to
implement DDCMP, and let some random RPi or virtual machine bridge the
KS' DECnet to the rest of the world.
Yeah. Not sure if PyDECnet have DDCMP yet, but of course, that could be
implemented.
And then it's the same story there. Packets come in, packets go out, and
internally it's just another circuit.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
3:20 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
Dave McGuire <mcguire(a)neurotica.com> wrote:
Of course another interesting option would be for pyDECnet to
implement DDCMP, and let some random RPi or virtual machine bridge the
KS' DECnet to the rest of the world.
You'd need a synchronous interface for your RPi. At one time there were sync serial
cards for ISA and PCI bus, but I'm not sure anybody's making them anymore. Maybe
somebody made a USB one?
Bob
3:23 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 21:20, Robert Armstrong wrote:
I could put that together pretty easily.
But what about DECnet over async? Suboptimal perhaps, but if the
goal is "get it talking"...would that be supported on the KS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Of course
another interesting option would be for pyDECnet to
implement DDCMP, and let some random RPi or virtual machine bridge the
KS' DECnet to the rest of the world.
You'd need a synchronous interface for your RPi. At one time there were sync
serial cards for ISA and PCI bus, but I'm not sure anybody's making them anymore.
Maybe somebody made a USB one?
3:36 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
Dave McGuire <mcguire(a)neurotica.com> wrote:
But what about DECnet over async?
Not sure that TOPS-10 supports async DECnet. VMS does, but I don't know
about TOPS-10.
And even if it does, the 2020 only supports a DZ11 terminal interface,
which is a character by character interrupt device (i.e. no silo). Given
that and the limited UBA bandwidth in the KS10, I don't think it would be a
good idea.
Bob
3:40 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 2022-09-11 03:36, Robert Armstrong wrote:
RSX does too, but not so sure about any other DEC OS.
Dave McGuire
<mcguire(a)neurotica.com> wrote:
But what about DECnet over async?
Not sure that TOPS-10 supports async DECnet. VMS does, but I don't know
about TOPS-10. And even if it does, the 2020 only supports a DZ11
terminal interface,
which is a character by character interrupt device (i.e. no silo). Given
that and the limited UBA bandwidth in the KS10, I don't think it would be a
good idea.
Yeah. It's actually a pretty horrible idea. RSX have drivers for running
async DDCMP over DZ, but it's definitely one of those "if you have
anything else, you should probably use that".
However, the DZ do have SILOs. Otherwise it would run a high risk of
loosing characters. But it's still lots of input interrupts. But that's
not the really bad thing. Most (if not all) DEC serial line interfaces
do lots of interrupts on input. However, the DZ does it also on output,
which is the horrible part. Other interfaces, such as the DH does DMA
for output, which obviously is *way* better.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
4:59 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 21:40, Johnny Billquist wrote:
Yeah. It's actually a pretty horrible idea. RSX
have drivers for running
async DDCMP over DZ, but it's definitely one of those "if you have
anything else, you should probably use that".
However, the DZ do have SILOs. Otherwise it would run a high risk of
loosing characters. But it's still lots of input interrupts. But that's
not the really bad thing. Most (if not all) DEC serial line interfaces
do lots of interrupts on input. However, the DZ does it also on output,
which is the horrible part. Other interfaces, such as the DH does DMA
for output, which obviously is *way* better.
Many years ago I was responsible for a VAX-11/750 in a commercial
environment. There were about a dozen terminals in offices, and two
printers, all connected via DZ11s. That poor machine was SLAMMED with
interrupts. When I took responsibility for that system, one of the
first things I did was replace the DZ11s with a DH11. It was such a
huge system-wide performance impact that people left various nice notes
and treats in my office for weeks.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
5:02 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/10/22 21:36, Robert Armstrong wrote:
VMS on VAX has code for DDCMP over async, but Alpha and Itanium do not.
But what
about DECnet over async?
Not sure that TOPS-10 supports async DECnet. VMS does, but I don't know
about TOPS-10. And even if it does, the 2020 only supports a DZ11
terminal interface,
which is a character by character interrupt device (i.e. no silo). Given
that and the limited UBA bandwidth in the KS10, I don't think it would be a
good idea.
Well, remember we're talking about a museum environment, not a
production environment. I'm just looking for an achievable way to get
it online.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
5:23 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
Dave,
Well, remember we're talking about a museum
environment, not a
production environment. I'm just looking for an achievable way to get
it online.
Get a sync DDCMP interface on some other box that runs a DECnet L1
router and can talk to the rest of the world.
-P
Ps: there is some additional work on the cisco suggestion, cisco
assumes DECnet Ethernet frames and there are differences on
how for example routing vectors are sent on a PtP link vs an Ethernet.
Once upon a time when we put the IP code in to the 7.02/t.03 merged code for
KI10's we used the serial interface on one of the non master CPU's to talk
SLIP while debugging... -:)
----- Original Message -----
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 11:02:04 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of non-optimal setup
> On 9/10/22 21:36, Robert Armstrong wrote:
>>> But what about DECnet over async?
>>
>> Not sure that TOPS-10 supports async DECnet. VMS does, but I don't know
>> about TOPS-10.
>
> VMS on VAX has code for DDCMP over async, but Alpha and Itanium do not.
>
>> And even if it does, the 2020 only supports a DZ11 terminal interface,
>> which is a character by character interrupt device (i.e. no silo). Given
>> that and the limited UBA bandwidth in the KS10, I don't think it would be a
>> good idea.
>
Well, remember we're talking about a museum
environment, not a
production environment. I'm just looking for an achievable way to get
it online.
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
> _______________________________________________
> HECnet mailing list -- hecnet(a)lists.dfupdate.se
> To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
5:29 p.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On Sep 10, 2022, at 11:23 PM, Peter Lothberg
<roll(a)stupi.com> wrote:
Dave,
A router that connects Ethernet to a point to point link takes care of that. And routing
vector messages are actually identical on both. What's different are the link
initialization messages (hello and, for point to point, the init messages) and the headers
on data frames.
paul
Well, remember we're talking about a museum
environment, not a
production environment. I'm just looking for an achievable way to get
it online.
Get a sync DDCMP interface on some other box that runs a DECnet L1
router and can talk to the rest of the world.
-P
Ps: there is some additional work on the cisco suggestion, cisco
assumes DECnet Ethernet frames and there are differences on
how for example routing vectors are sent on a PtP link vs an Ethernet.
7:06 p.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
You had Tops-10 speaking IP?? Whaay cool! I don't recall there being
more than a handful of Tops-10 machines on the ARPAnet and was saddened
that the official product never adopted it. Are those sources
anywhere? Maybe some worthy Tops-10 wizard might put them into a
hobbyist release.
Tops-20 supports SLIP. Like the IPNI and IPCI keywords, you can put a
SERIAL entry into SYSTEM:INTERNET.GATEWAYS. I had thought this was how
MRC continued to send messages from LingLing to Tops-20-Wizards. I
don't immediately remember him talking about either of his 2020's having
Ethernet. This, of course, means nothing...
This is part of the multinet code. which suggests that it could be
adapted to asynchronous DECnet. I'm not saying that's a great idea,
just that it might be an interesting one. Probably a better approach
would be to implement an MCB front end like what has been done with Chaos.
------------------------------------------------------------------------
On 9/10/22 11:23 PM, Peter Lothberg wrote:
Once upon a time when we put the IP code in to the 7.02/t.03 merged code for KI10's
we used the serial interface on one of the non master CPU's to talk SLIP while
debugging... -:)
3:39 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
Is there KMC-11 code for HDLC? The DUP-11 to my memory would not
get in the way of HDLC.
If you want to talk to a cisco sync interface, put the DECnet packet
in a cisco HDLC frame. You can turn off all the keep alive/rarp humbo
jumbo that goes on between two cisco boxes.
The FCS is 16 bit CRC for slow links and 32 bit for "fast" links.
-P
cisco Serial Line Encapsulation
-------------------------------
cisco's default encapsulation on synchronous serial lines uses HDLC framing,
with packet contents defined as follows:
The first ("address") octet is set to 0x0F for unicast packets and 0x8F
for broadcast packets. Broadcast just means that the higher-level protocol
thought this was a broadcast packet; cisco doesn't support multidrop
HDLC at this time.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent most-significant-first.
These codes are usually Ethernet type codes. cisco has added some codes to
support packet types that don't appear on Ethernets. The current list of codes
is as follows:
TYPE_PUP 0x0200 PUP
TYPE_XNS 0x0600 XNS
TYPE_IP10MB 0x0800 IP
TYPE_CHAOS 0x0804 Chaos
TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot.
TYPE_DECNET 0x6003 DECnet phase IV
TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
TYPE_APOLLO 0x8019 Apollo domain
TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!)
TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol
TYPE_ETHERTALK 0x809b Apple EtherTalk
TYPE_AARP 0x80f3 Appletalk ARP
TYPE_NOVELL1 0x8137 Novell IPX
TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
This list is shared between serial and Ethernet encapsulations. Not all
these codes will necessarily appear on serial lines. This list will probably
be extended as cisco adds support for more protocols.
Bytes after this are higher-level protocol data. These normally look the
same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers to
as SLARP. SLARP has two functions: dynamic IP address determination and
serial line keepalive.
The serial line model supported by SLARP assumes that each serial line is
a separate IP subnet, and that one end of the line is host number 1, while
the other end is host number 2. The SLARP address resolution protocol allows
system A to request that system B tell system A system B's IP address,
along with the IP netmask to be used on the network. It does this by sending
a SLARP address resolution request packet, to which system B responds with a
SLARP address resolution reply packet. System A then attempts to determine its
own IP address based on the address of system B. If the host portion of system
B's address is 1, system A will use 2 for the host portion of its own IP
address. Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than 1 or 2,
system A assumes that system B is unable to provide it with an address via
SLARP.
For the SLARP keepalive protocol, each system sends the other a keepalive
packet at a user-configurable interval. The default interval is 10 seconds.
Both systems must use the same interval to ensure reliable operation.
Each system assigns sequence numbers to the keepalive packets it sends,
starting with zero, independent of the other system. These sequence numbers
are included in the keepalive packets sent to the other system. Also included
in each keepalive packet is the sequence number of the last keepalive packet
_received_ from the other system, as assigned by the other system. This number
is called the returned sequence number. Each system keeps track of the last
returned sequence number it has received. Immediately before sending a keepalive
packet, it compares the sequence number of the packet it is about to send with
the returned sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line to have failed, and
will route no further higher-level data across it until an acceptable keepalive
response is received.
There is interaction between the SLARP address resolution protocol and the
SLARP keepalive protocol. When one end of a serial line receives a SLARP
address resolution request packet, it assumes that the other end has restarted
its serial interface and reset its keepalive sequence numbers. In addition
to responding to the address resolution request, it will act as if the
other end had sent it a keepalive packet with a sequence number of zero,
and a returned sequence number the same as the returned sequence number
of the last real keepalive packet it received from the other end.
The following is a C definition for the SLARP packet. The "long" and
"ulong"
types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit
number, high octet sent first.
struct slarp {
long code; /* SLARP packet type code */
union sl { /* followed by one of: */
struct { /* Address resolution functions */
ulong address; /* Address of system sending this pkt */
ulong mask; /* IP subnet mask for this line */
ushort unused; /* Unused: contents undefined */
} add; /* -- or -- */
struct { /* Keepalive probing functions */
ulong mysequence; /* Outgoing sequence number */
ulong yoursequence; /* Returned sequence number */
ushort reliability; /* Reserved: set to FFFF */
} chk;
} t;
};
Note that the data storage for t.add is overlayed on the data storage for
t.chk. The whole SLARP packet consists of a 32-bit type code, followed by
two 32-bit quantities and one 16-bit quantity. The overall length of the
SLARP packet is 14 octets. The "code" field is used to identify the
packet's
SLARP type. Legal values for the "code" field are as follows:
SLARP_REQUEST 0 Address resolution request
SLARP_REPLY 1 Address resolution reply
SLARP_LINECHECK 2 Line keepalive
For address resolution request packets, the "address" and "mask"
fields are
set to zero, and the contents of the "unused" field field are undefined. For
address resolution reply packets, the "address" field contains the IP address
of the _replying_ system, and the "mask" field contains the IP subnet mask
to be used. The contents of the "unused" field are undefined.
For keepalive packets, the "mysequence" field contains the sequence number
of the packet and the "yoursequence" field contains the returned sequence
number, which is the sequence number of the last keepalive packet the sending
system has gotten from the receiving system. The "reliability" field is
reserved for future use, and _must_ be set to FFFF hexadecimal.
----- Original Message -----
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 9:23:05 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of non-optimal setup
I could put that together pretty easily.
But what about DECnet over async? Suboptimal perhaps, but if the
goal is "get it talking"...would that be supported on the KS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
3:44 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On Tops10 with a DN87 you can speak DDCMP on SYNC or ASYNC lines,
and chose if you want ANF10 speak, or the "DDP" device that enables
you to put any user data in the DDCMP packet. (Like Phase 4 to bypass
the MCB or speak IP to a DMR/DMC in a VAXEN running BSD 4.3..)
The KS can not speak DDCMP with the monitor, it's the KMC.
(You are better off hacking the 8080 to use the klink line for
async DDCMP than using the DZ11, as Bob is hinting..)
-P
----- Original Message -----
From: "Peter Lothberg"
<roll(a)stupi.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 9:39:56 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of non-optimal setup
Is there KMC-11 code for HDLC? The DUP-11 to my memory
would not
get in the way of HDLC.
If you want to talk to a cisco sync interface, put the DECnet packet
in a cisco HDLC frame. You can turn off all the keep alive/rarp humbo
jumbo that goes on between two cisco boxes.
The FCS is 16 bit CRC for slow links and 32 bit for "fast" links.
-P
cisco Serial Line Encapsulation
-------------------------------
cisco's default encapsulation on synchronous serial lines uses HDLC framing,
with packet contents defined as follows:
The first ("address") octet is set to 0x0F for unicast packets and 0x8F
for broadcast packets. Broadcast just means that the higher-level protocol
thought this was a broadcast packet; cisco doesn't support multidrop
HDLC at this time.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent most-significant-first.
These codes are usually Ethernet type codes. cisco has added some codes to
support packet types that don't appear on Ethernets. The current list of codes
is as follows:
TYPE_PUP 0x0200 PUP
TYPE_XNS 0x0600 XNS
TYPE_IP10MB 0x0800 IP
TYPE_CHAOS 0x0804 Chaos
TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot.
TYPE_DECNET 0x6003 DECnet phase IV
TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
TYPE_APOLLO 0x8019 Apollo domain
TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!)
TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol
TYPE_ETHERTALK 0x809b Apple EtherTalk
TYPE_AARP 0x80f3 Appletalk ARP
TYPE_NOVELL1 0x8137 Novell IPX
TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
This list is shared between serial and Ethernet encapsulations. Not all
these codes will necessarily appear on serial lines. This list will probably
be extended as cisco adds support for more protocols.
Bytes after this are higher-level protocol data. These normally look the
same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers to
as SLARP. SLARP has two functions: dynamic IP address determination and
serial line keepalive.
The serial line model supported by SLARP assumes that each serial line is
a separate IP subnet, and that one end of the line is host number 1, while
the other end is host number 2. The SLARP address resolution protocol allows
system A to request that system B tell system A system B's IP address,
along with the IP netmask to be used on the network. It does this by sending
a SLARP address resolution request packet, to which system B responds with a
SLARP address resolution reply packet. System A then attempts to determine its
own IP address based on the address of system B. If the host portion of system
B's address is 1, system A will use 2 for the host portion of its own IP
address. Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than 1 or 2,
system A assumes that system B is unable to provide it with an address via
SLARP.
For the SLARP keepalive protocol, each system sends the other a keepalive
packet at a user-configurable interval. The default interval is 10 seconds.
Both systems must use the same interval to ensure reliable operation.
Each system assigns sequence numbers to the keepalive packets it sends,
starting with zero, independent of the other system. These sequence numbers
are included in the keepalive packets sent to the other system. Also included
in each keepalive packet is the sequence number of the last keepalive packet
_received_ from the other system, as assigned by the other system. This number
is called the returned sequence number. Each system keeps track of the last
returned sequence number it has received. Immediately before sending a keepalive
packet, it compares the sequence number of the packet it is about to send with
the returned sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line to have failed, and
will route no further higher-level data across it until an acceptable keepalive
response is received.
There is interaction between the SLARP address resolution protocol and the
SLARP keepalive protocol. When one end of a serial line receives a SLARP
address resolution request packet, it assumes that the other end has restarted
its serial interface and reset its keepalive sequence numbers. In addition
to responding to the address resolution request, it will act as if the
other end had sent it a keepalive packet with a sequence number of zero,
and a returned sequence number the same as the returned sequence number
of the last real keepalive packet it received from the other end.
The following is a C definition for the SLARP packet. The "long" and
"ulong"
types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit
number, high octet sent first.
struct slarp {
long code; /* SLARP packet type code */
union sl { /* followed by one of: */
struct { /* Address resolution functions */
ulong address; /* Address of system sending this pkt */
ulong mask; /* IP subnet mask for this line */
ushort unused; /* Unused: contents undefined */
} add; /* -- or -- */
struct { /* Keepalive probing functions */
ulong mysequence; /* Outgoing sequence number */
ulong yoursequence; /* Returned sequence number */
ushort reliability; /* Reserved: set to FFFF */
} chk;
} t;
};
Note that the data storage for t.add is overlayed on the data storage for
t.chk. The whole SLARP packet consists of a 32-bit type code, followed by
two 32-bit quantities and one 16-bit quantity. The overall length of the
SLARP packet is 14 octets. The "code" field is used to identify the
packet's
SLARP type. Legal values for the "code" field are as follows:
SLARP_REQUEST 0 Address resolution request
SLARP_REPLY 1 Address resolution reply
SLARP_LINECHECK 2 Line keepalive
For address resolution request packets, the "address" and "mask"
fields are
set to zero, and the contents of the "unused" field field are undefined. For
address resolution reply packets, the "address" field contains the IP address
of the _replying_ system, and the "mask" field contains the IP subnet mask
to be used. The contents of the "unused" field are undefined.
For keepalive packets, the "mysequence" field contains the sequence number
of the packet and the "yoursequence" field contains the returned sequence
number, which is the sequence number of the last keepalive packet the sending
system has gotten from the receiving system. The "reliability" field is
reserved for future use, and _must_ be set to FFFF hexadecimal.
3:51 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
I've not seen/heard of HDLC microcode for the KMC. But I guess it would
be theoretically possible. But I wonder if anyone have the docs and
tools to create new firmware for the KMC today...
Johnny
On 2022-09-11 03:39, Peter Lothberg wrote:
Is there KMC-11 code for HDLC? The DUP-11 to my memory
would not
get in the way of HDLC.
If you want to talk to a cisco sync interface, put the DECnet packet
in a cisco HDLC frame. You can turn off all the keep alive/rarp humbo
jumbo that goes on between two cisco boxes.
The FCS is 16 bit CRC for slow links and 32 bit for "fast" links.
-P
cisco Serial Line Encapsulation
-------------------------------
cisco's default encapsulation on synchronous serial lines uses HDLC framing,
with packet contents defined as follows:
The first ("address") octet is set to 0x0F for unicast packets and 0x8F
for broadcast packets. Broadcast just means that the higher-level protocol
thought this was a broadcast packet; cisco doesn't support multidrop
HDLC at this time.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent most-significant-first.
These codes are usually Ethernet type codes. cisco has added some codes to
support packet types that don't appear on Ethernets. The current list of codes
is as follows:
TYPE_PUP 0x0200 PUP
TYPE_XNS 0x0600 XNS
TYPE_IP10MB 0x0800 IP
TYPE_CHAOS 0x0804 Chaos
TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot.
TYPE_DECNET 0x6003 DECnet phase IV
TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
TYPE_APOLLO 0x8019 Apollo domain
TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!)
TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol
TYPE_ETHERTALK 0x809b Apple EtherTalk
TYPE_AARP 0x80f3 Appletalk ARP
TYPE_NOVELL1 0x8137 Novell IPX
TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
This list is shared between serial and Ethernet encapsulations. Not all
these codes will necessarily appear on serial lines. This list will probably
be extended as cisco adds support for more protocols.
Bytes after this are higher-level protocol data. These normally look the
same as they'd look on Ethernet. Bridging packets include Ethernet/802.3
MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers to
as SLARP. SLARP has two functions: dynamic IP address determination and
serial line keepalive.
The serial line model supported by SLARP assumes that each serial line is
a separate IP subnet, and that one end of the line is host number 1, while
the other end is host number 2. The SLARP address resolution protocol allows
system A to request that system B tell system A system B's IP address,
along with the IP netmask to be used on the network. It does this by sending
a SLARP address resolution request packet, to which system B responds with a
SLARP address resolution reply packet. System A then attempts to determine its
own IP address based on the address of system B. If the host portion of system
B's address is 1, system A will use 2 for the host portion of its own IP
address. Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than 1 or 2,
system A assumes that system B is unable to provide it with an address via
SLARP.
For the SLARP keepalive protocol, each system sends the other a keepalive
packet at a user-configurable interval. The default interval is 10 seconds.
Both systems must use the same interval to ensure reliable operation.
Each system assigns sequence numbers to the keepalive packets it sends,
starting with zero, independent of the other system. These sequence numbers
are included in the keepalive packets sent to the other system. Also included
in each keepalive packet is the sequence number of the last keepalive packet
_received_ from the other system, as assigned by the other system. This number
is called the returned sequence number. Each system keeps track of the last
returned sequence number it has received. Immediately before sending a keepalive
packet, it compares the sequence number of the packet it is about to send with
the returned sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line to have failed, and
will route no further higher-level data across it until an acceptable keepalive
response is received.
There is interaction between the SLARP address resolution protocol and the
SLARP keepalive protocol. When one end of a serial line receives a SLARP
address resolution request packet, it assumes that the other end has restarted
its serial interface and reset its keepalive sequence numbers. In addition
to responding to the address resolution request, it will act as if the
other end had sent it a keepalive packet with a sequence number of zero,
and a returned sequence number the same as the returned sequence number
of the last real keepalive packet it received from the other end.
The following is a C definition for the SLARP packet. The "long" and
"ulong"
types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit
number, high octet sent first.
struct slarp {
long code; /* SLARP packet type code */
union sl { /* followed by one of: */
struct { /* Address resolution functions */
ulong address; /* Address of system sending this pkt */
ulong mask; /* IP subnet mask for this line */
ushort unused; /* Unused: contents undefined */
} add; /* -- or -- */
struct { /* Keepalive probing functions */
ulong mysequence; /* Outgoing sequence number */
ulong yoursequence; /* Returned sequence number */
ushort reliability; /* Reserved: set to FFFF */
} chk;
} t;
};
Note that the data storage for t.add is overlayed on the data storage for
t.chk. The whole SLARP packet consists of a 32-bit type code, followed by
two 32-bit quantities and one 16-bit quantity. The overall length of the
SLARP packet is 14 octets. The "code" field is used to identify the
packet's
SLARP type. Legal values for the "code" field are as follows:
SLARP_REQUEST 0 Address resolution request
SLARP_REPLY 1 Address resolution reply
SLARP_LINECHECK 2 Line keepalive
For address resolution request packets, the "address" and "mask"
fields are
set to zero, and the contents of the "unused" field field are undefined. For
address resolution reply packets, the "address" field contains the IP address
of the _replying_ system, and the "mask" field contains the IP subnet mask
to be used. The contents of the "unused" field are undefined.
For keepalive packets, the "mysequence" field contains the sequence number
of the packet and the "yoursequence" field contains the returned sequence
number, which is the sequence number of the last keepalive packet the sending
system has gotten from the receiving system. The "reliability" field is
reserved for future use, and _must_ be set to FFFF hexadecimal.
----- Original Message -----
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 9:23:05 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of non-optimal setup
I could put that together pretty easily.
But what about DECnet over async? Suboptimal perhaps, but if the
goal is "get it talking"...would that be supported on the KS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
4:05 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
I've not seen/heard of HDLC microcode for the KMC.
But I guess it would
be theoretically possible. But I wonder if anyone have the docs and
tools to create new firmware for the KMC today...
Johnny
Bitsavers have all you need, any of the DEC microcode assemblers can
be used, or paper and pen..
--P
http://www.bitsavers.org/pdf/dec/unibus/EK-KMC1B-UG-001_KMC11B_ug.pdf
http://www.bitsavers.org/pdf/dec/unibus/KMC11_PrelimUsersMan.pdf
http://www.bitsavers.org/pdf/dec/unibus/KMC11_ProgMan.pdf
4:12 p.m.
Non-optimal no longer!
The GRE link between area routers ONAPI4 (Area 29) and A34RTR (Area 34) is
now up and running.
Thanks Tomas!
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Sunday, September 11, 2022 3:52 AM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of
non-optimal setup
I've not seen/heard of HDLC microcode for the KMC. But I guess it would be
theoretically possible. But I wonder if anyone have the docs and tools to
create new firmware for the KMC today...
Johnny
On 2022-09-11 03:39, Peter Lothberg wrote:
Is there KMC-11 code for HDLC? The DUP-11 to my memory
would not get
in the way of HDLC.
If you want to talk to a cisco sync interface, put the DECnet packet
in a cisco HDLC frame. You can turn off all the keep alive/rarp humbo
jumbo that goes on between two cisco boxes.
The FCS is 16 bit CRC for slow links and 32 bit for "fast" links.
-P
cisco Serial Line Encapsulation
-------------------------------
cisco's default encapsulation on synchronous serial lines uses HDLC
framing, with packet contents defined as follows:
The first ("address") octet is set to 0x0F for unicast packets and
0x8F for broadcast packets. Broadcast just means that the higher-level
protocol thought this was a broadcast packet; cisco doesn't support
multidrop HDLC at this time.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent
most-significant-first.
These codes are usually Ethernet type codes. cisco has
added some
codes to support packet types that don't appear on Ethernets. The
current list of codes is as follows:
TYPE_PUP 0x0200 PUP
TYPE_XNS 0x0600 XNS
TYPE_IP10MB 0x0800 IP
TYPE_CHAOS 0x0804 Chaos
TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge
spanning prot.
TYPE_DECNET 0x6003 DECnet phase
IV
TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
TYPE_APOLLO 0x8019 Apollo domain
TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse
ARP!)
TYPE_DEC_SPANNING 0x8038 DEC bridge
spanning tree protocol
TYPE_ETHERTALK 0x809b Apple EtherTalk
TYPE_AARP 0x80f3 Appletalk ARP
TYPE_NOVELL1 0x8137 Novell IPX
TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
This list is shared between serial and Ethernet encapsulations. Not
all these codes will necessarily appear on serial lines. This list
will probably be extended as cisco adds support for more protocols.
Bytes after this are higher-level protocol data. These normally look
the same as they'd look on Ethernet. Bridging packets include
Ethernet/802.3 MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers
to as SLARP. SLARP has two functions: dynamic IP address determination
and serial line keepalive.
The serial line model supported by SLARP assumes that each serial line
is a separate IP subnet, and that one end of the line is host number
1, while the other end is host number 2. The SLARP address resolution
protocol allows system A to request that system B tell system A system
B's IP address, along with the IP netmask to be used on the network.
It does this by sending a SLARP address resolution request packet, to
which system B responds with a SLARP address resolution reply packet.
System A then attempts to determine its own IP address based on the
address of system B. If the host portion of system B's address is 1,
system A will use 2 for the host portion of its own IP address.
Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than
1 or 2, system A assumes that system B is unable to provide it with an
address via
SLARP.
For the SLARP keepalive protocol, each system sends the other a
keepalive packet at a user-configurable interval. The default interval is
10
seconds.
Both systems must use the same interval to ensure
reliable operation.
Each system assigns sequence numbers to the keepalive packets it
sends, starting with zero, independent of the other system. These
sequence numbers are included in the keepalive packets sent to the
other system. Also included in each keepalive packet is the sequence
number of the last keepalive packet _received_ from the other system,
as assigned by the other system. This number is called the returned
sequence number. Each system keeps track of the last returned sequence
number it has received. Immediately before sending a keepalive packet,
it compares the sequence number of the packet it is about to send with the
returned
sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line
to have failed,
and will route no further higher-level data across it until an
acceptable keepalive response is received.
There is interaction between the SLARP address resolution protocol and
the SLARP keepalive protocol. When one end of a serial line receives a
SLARP address resolution request packet, it assumes that the other end
has restarted its serial interface and reset its keepalive sequence
numbers. In addition to responding to the address resolution request,
it will act as if the other end had sent it a keepalive packet with a
sequence number of zero, and a returned sequence number the same as
the returned sequence number of the last real keepalive packet it received
from the
other end.
The following is a C definition for the SLARP packet. The "long" and
"ulong"
types are 32-bit numbers, high octet sent first. The
"ushort" type is
a 16-bit number, high octet sent first.
struct slarp {
long code; /* SLARP packet type code */
union sl { /* followed by one of: */
struct { /* Address resolution functions
*/
ulong address; /* Address of
system sending this
pkt */
ulong mask; /* IP subnet
mask for this line
*/
ushort unused; /* Unused:
contents undefined */
} add; /* -- or -- */
struct { /* Keepalive probing functions */
ulong mysequence; /* Outgoing sequence number */
ulong yoursequence; /* Returned sequence number */
ushort reliability; /* Reserved: set to FFFF */
} chk;
} t;
};
Note that the data storage for t.add is overlayed on the data storage
for t.chk. The whole SLARP packet consists of a 32-bit type code,
followed by two 32-bit quantities and one 16-bit quantity. The overall
length of the SLARP packet is 14 octets. The "code" field is used to
identify the packet's SLARP type. Legal values for the "code" field are as
follows:
SLARP_REQUEST 0 Address resolution request
SLARP_REPLY 1 Address resolution reply
SLARP_LINECHECK 2 Line keepalive
For address resolution request packets, the "address" and "mask"
fields are set to zero, and the contents of the "unused" field field
are undefined. For address resolution reply packets, the "address"
field contains the IP address of the _replying_ system, and the "mask"
field contains the IP subnet mask to be used. The contents of the "unused"
field are undefined.
For keepalive packets, the "mysequence" field contains the sequence
number of the packet and the "yoursequence" field contains the
returned sequence number, which is the sequence number of the last
keepalive packet the sending system has gotten from the receiving
system. The "reliability" field is reserved for future use, and _must_ be
set to FFFF hexadecimal.
----- Original Message -----
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 9:23:05 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of
non-optimal setup
I could put that together pretty easily.
But what about DECnet over async? Suboptimal perhaps, but if the
goal is "get it talking"...would that be supported on the KS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se
4:15 p.m.
Thank you Wilm for you quick assistance and response.
And thank you all for getting my attention to the problem.
We might have another trick to add another path locally in Sweden but that's a later
story.
BR
/t
Den 2022-09-11 16:12 skrev "Wilm Boerhout" <wboerhout(a)gmail.com>
följande:
Non-optimal no longer!
The GRE link between area routers ONAPI4 (Area 29) and A34RTR (Area 34) is
now up and running.
Thanks Tomas!
Wilm
-----Original Message-----
From: Johnny Billquist <bqt(a)softjar.se>
Sent: Sunday, September 11, 2022 3:52 AM
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of
non-optimal setup
I've not seen/heard of HDLC microcode for the KMC. But I guess it would be
theoretically possible. But I wonder if anyone have the docs and tools to
create new firmware for the KMC today...
Johnny
On 2022-09-11 03:39, Peter Lothberg wrote:
Is there KMC-11 code for HDLC? The DUP-11 to my memory
would not get
in the way of HDLC.
If you want to talk to a cisco sync interface, put the DECnet packet
in a cisco HDLC frame. You can turn off all the keep alive/rarp humbo
jumbo that goes on between two cisco boxes.
The FCS is 16 bit CRC for slow links and 32 bit for "fast" links.
-P
cisco Serial Line Encapsulation
-------------------------------
cisco's default encapsulation on synchronous serial lines uses HDLC
framing, with packet contents defined as follows:
The first ("address") octet is set to 0x0F for unicast packets and
0x8F for broadcast packets. Broadcast just means that the higher-level
protocol thought this was a broadcast packet; cisco doesn't support
multidrop HDLC at this time.
The second ("control") octet is always 0.
The next two octets are a 16-bit protocol code, sent
most-significant-first.
These codes are usually Ethernet type codes. cisco has
added some
codes to support packet types that don't appear on Ethernets. The
current list of codes is as follows:
TYPE_PUP 0x0200 PUP
TYPE_XNS 0x0600 XNS
TYPE_IP10MB 0x0800 IP
TYPE_CHAOS 0x0804 Chaos
TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge
spanning
prot.
TYPE_DECNET 0x6003 DECnet phase
IV
TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet
TYPE_APOLLO 0x8019 Apollo domain
TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse
ARP!)
TYPE_DEC_SPANNING 0x8038 DEC bridge
spanning tree protocol
TYPE_ETHERTALK 0x809b Apple EtherTalk
TYPE_AARP 0x80f3 Appletalk ARP
TYPE_NOVELL1 0x8137 Novell IPX
TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP
This list is shared between serial and Ethernet encapsulations. Not
all these codes will necessarily appear on serial lines. This list
will probably be extended as cisco adds support for more protocols.
Bytes after this are higher-level protocol data. These normally look
the same as they'd look on Ethernet. Bridging packets include
Ethernet/802.3 MAC headers; no other packets do.
Packets with type 8035 (reverse ARP) don't contain reverse ARP data as
they would on an Ethernet. Instead, they carry a protocol cisco refers
to as SLARP. SLARP has two functions: dynamic IP address determination
and serial line keepalive.
The serial line model supported by SLARP assumes that each serial line
is a separate IP subnet, and that one end of the line is host number
1, while the other end is host number 2. The SLARP address resolution
protocol allows system A to request that system B tell system A system
B's IP address, along with the IP netmask to be used on the network.
It does this by sending a SLARP address resolution request packet, to
which system B responds with a SLARP address resolution reply packet.
System A then attempts to determine its own IP address based on the
address of system B. If the host portion of system B's address is 1,
system A will use 2 for the host portion of its own IP address.
Conversely, if system B's IP host number is 2, system A will use IP
host number 1. If system B replies with any IP host number other than
1 or 2, system A assumes that system B is unable to provide it with an
address
via SLARP.
For the SLARP keepalive protocol, each system sends the other a
keepalive packet at a user-configurable interval. The default interval is
10
seconds.
Both systems must use the same interval to ensure
reliable operation.
Each system assigns sequence numbers to the keepalive packets it
sends, starting with zero, independent of the other system. These
sequence numbers are included in the keepalive packets sent to the
other system. Also included in each keepalive packet is the sequence
number of the last keepalive packet _received_ from the other system,
as assigned by the other system. This number is called the returned
sequence number. Each system keeps track of the last returned sequence
number it has received. Immediately before sending a keepalive packet,
it compares the sequence number of the packet it is about to send with the
returned sequence number in the last keepalive packet it has received.
If the two differ by 3 or more, it considers the line
to have failed,
and will route no further higher-level data across it until an
acceptable keepalive response is received.
There is interaction between the SLARP address resolution protocol and
the SLARP keepalive protocol. When one end of a serial line receives a
SLARP address resolution request packet, it assumes that the other end
has restarted its serial interface and reset its keepalive sequence
numbers. In addition to responding to the address resolution request,
it will act as if the other end had sent it a keepalive packet with a
sequence number of zero, and a returned sequence number the same as
the returned sequence number of the last real keepalive packet it received
from
the other end.
The following is a C definition for the SLARP packet. The "long" and
"ulong"
types are 32-bit numbers, high octet sent first. The
"ushort" type is
a 16-bit number, high octet sent first.
struct slarp {
long code; /* SLARP packet type code */
union sl { /* followed by one of: */
struct { /* Address resolution functions
*/
ulong address; /* Address of
system sending this
pkt */
ulong mask; /* IP subnet
mask for this line
*/
ushort unused; /* Unused:
contents undefined */
} add; /* -- or -- */
struct { /* Keepalive probing functions */
ulong mysequence; /* Outgoing sequence number */
ulong yoursequence; /* Returned sequence number */
ushort reliability; /* Reserved: set to FFFF */
} chk;
} t;
};
Note that the data storage for t.add is overlayed on the data storage
for t.chk. The whole SLARP packet consists of a 32-bit type code,
followed by two 32-bit quantities and one 16-bit quantity. The overall
length of the SLARP packet is 14 octets. The "code" field is used to
identify the packet's SLARP type. Legal values for the "code" field are as
follows:
SLARP_REQUEST 0 Address resolution request
SLARP_REPLY 1 Address resolution reply
SLARP_LINECHECK 2 Line keepalive
For address resolution request packets, the "address" and "mask"
fields are set to zero, and the contents of the "unused" field field
are undefined. For address resolution reply packets, the "address"
field contains the IP address of the _replying_ system, and the "mask"
field contains the IP subnet mask to be used. The contents of the "unused"
field are undefined.
For keepalive packets, the "mysequence" field contains the sequence
number of the packet and the "yoursequence" field contains the
returned sequence number, which is the sequence number of the last
keepalive packet the sending system has gotten from the receiving
system. The "reliability" field is reserved for future use, and _must_ be
set to FFFF hexadecimal.
----- Original Message -----
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
From: "Dave McGuire"
<mcguire(a)neurotica.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Saturday, September 10, 2022 9:23:05 PM
Subject: [HECnet] Re: Networking a KS10, was Re: Re: An example of
non-optimal setup
I could put that together pretty easily.
But what about DECnet over async? Suboptimal perhaps, but if the
goal is "get it talking"...would that be supported on the KS?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send
an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an
email to hecnet-leave(a)lists.dfupdate.se 
12 Sep
12 Sep
11:18 a.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On Sun, 11 Sept 2022 at 02:52, Johnny Billquist <bqt(a)softjar.se> wrote:
I've not seen/heard of HDLC microcode for the KMC.
But I guess it would
be theoretically possible. But I wonder if anyone have the docs and
tools to create new firmware for the KMC today...
VAX P.S.I. in DECnet Phase IV used to support KMC11-based devices. I think
the microcode even did LAPB on board, leaving the host to do X.25 L3 only.
In practice this was more trouble than it was worth, and these devices were
not supported for Phase V.
11 Sep
11 Sep
5:27 p.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On Sep 10, 2022, at 9:10 PM, Dave McGuire
<mcguire(a)neurotica.com> wrote:
On 9/10/22 21:08, Johnny Billquist wrote:
Certainly. If you just have an RSX routing node with both interfaces, you will have the
capability of connecting both sides.
That sounds like an interesting solution. I've never routed/bridged DECnet in that
way.
Of course another interesting option would be for pyDECnet to implement DDCMP, and let
some random RPi or virtual machine bridge the KS' DECnet to the rest of the world.
Are you talking a real KS or an emulated one?
If a real one, you'd need to connect to a router that implement DDCMP over a
synchronous link. A PDP11 with a DMC11 (DMV if it's Qbus) or RSX system with a DUP
could do the job. With PyDECnet, you can do it if you built yourself one of my DDCMP sync
adapters, which is a small USB device that PyDECnet can talk to and use to speak DDCMP on
a sync link. For that matter, SIMH supports that adapter as well.
paul
The KMC/DUP speaks "DDCMP" that is not
spoken by a cisco router sync interface.
You need for example to run the sync line from the 2020 to a LSI-11 with
RSX (as you can get help from Johnny with rsx..) and a sync and Ethernet
interface in the 11. (Or any PDP11/VAX with a sync interface.)
(I'm an old hand at RSX)
So we could use a PDP-11 with a KMC11 to bridge DECnet over DDCMP to Ethernet?
5:30 p.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
On 9/11/22 11:27, Paul Koning wrote:
Sir, you wound me. A real KS10. Neither of them are running yet,
but we're getting there.
I'm very much interested in one of your USB<->DDCMP-async adapters.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Of course
another interesting option would be for pyDECnet to implement DDCMP, and let some random
RPi or virtual machine bridge the KS' DECnet to the rest of the world.
Are you talking a real KS or an emulated one?
If a real one, you'd need to connect to a router that implement DDCMP over a
synchronous link. A PDP11 with a DMC11 (DMV if it's Qbus) or RSX system with a DUP
could do the job. With PyDECnet, you can do it if you built yourself one of my DDCMP sync
adapters, which is a small USB device that PyDECnet can talk to and use to speak DDCMP on
a sync link. For that matter, SIMH supports that adapter as well.
7:06 p.m.
New subject: Networking a KS10, was Re: Re: An example of non-optimal setup
"complaining"? I had thought my observations were something more along
lines of "bewailing". The difference? It's not that Tops-20 doesn't do
something, which would be complaining. It's that I don't have the
sources to do something about it. How about whining? 😁
Seriously, because I have monitor and CUSP sources, I have been able to
fix a lot of bugs in Tops-20's DECnet implementation and related
software and also add enhancements. What does "a lot" mean? By my
count, 74, so far. I was really getting on a roll before I fell into
the Kermit-20 NRT black hole.
You are, of course, entirely correct about the Tops-10/Tops-20's DECnet
implementation only supporting end-node and level-1 router, yet this
wasn't quite what I was getting at. What I had in mind was taking the
information that Tops-20 discards in the router HELLO message and
putting it into a table so that this area information could be queried.
It doesn't matter that there is no JSYS interface to query it with, I
can't update NCU to have a user interface.
The reason I've been thinking about areas is that I have been wondering
about implementing changes to make Tops-20 be a level two router. Only
having Phase II NCU to work with is what I would call an 'unfortunate'
hurdle.
------------------------------------------------------------------------
On 9/10/22 7:34 PM, Peter Lothberg wrote:
TommyT was complaining that he could not get area info from T10/T20 that's because it
can either be end-node or level-1 router, not level 2 router.
7:21 p.m.
Yes, I meant to say KS.
The difference I was trying to make is that last official release of
Tops-10 on a KS supports Phase IV whereas the last official release of
Tops-20 does not.
Yes, these DN-somethings were called DN20's if they ran MCB (DECnet) and
DN60's if they ran the IBM communications software. The last release of
MCB was limited to Phase III routing. The hardware was whatever the
particular PDP-11 would support, I think they ran PDP-11/34's and not
the PDP-11/40 that the RSX20F master front-end ran.
Roughly speaking, I only remember there being two kinds of interfaces,
'fast' and 'slow'. The fast interface was called a KMC and would do
about 50K baud, asynchronous. I don't quite remember the name of the
slower interface or its speed, but maybe it did 9600 Bd.
On 9/10/22 5:13 PM, Robert Armstrong wrote:
A Tops-10 node
appears to be able to have separate connections via a KDP, viz:
It's not a
TOPS-10 issue; it's a KS10/2020 limitation because Ethernet is not supported on that
machine. The KDP is actually a combination of one KDP and one or more DUPs. Each DUP is
a single synchronous line interface and you can have up to four. They can be used for
either DECnet or ANF10. I believe that officially DECnet only supported one DUP line, but
in practice you could have more.
But on a KL10, of course, it's the same as for TOPS20 and normally you'd have
the NI20 Ethernet interface. But I'm pretty sure there was a DN-something front end
that supported synchronous DECnet circuits, so I would expect those were possible too.
Bob
9:20 p.m.
On tops10, you have DN87S on KL and DN87 on DL10/KI10.You bypass the MCB phase 3 stuff
by using the DDP device and "tunnel" phase4 to a IO device on the front end,
that can be
a ASYNC, SYNC or even Ethernet.
Look for "DDP" in tops10 dnadll.mac and netdev.mac.
-Peter
----- Original Message -----
From: "tommytimesharing"
<tommytimesharing(a)gmail.com>
To: "The Hobbyist DECnet mailing list" <hecnet(a)lists.dfupdate.se>
Sent: Sunday, September 11, 2022 1:21:35 PM
Subject: [HECnet] Re: An example of non-optimal setup
Yes, I meant to say KS.
The difference I was trying to make is that last official release of
Tops-10 on a KS supports Phase IV whereas the last official release of
Tops-20 does not.
Yes, these DN-somethings were called DN20's if they ran MCB (DECnet) and
DN60's if they ran the IBM communications software. The last release of
MCB was limited to Phase III routing. The hardware was whatever the
particular PDP-11 would support, I think they ran PDP-11/34's and not
the PDP-11/40 that the RSX20F master front-end ran.
Roughly speaking, I only remember there being two kinds of interfaces,
'fast' and 'slow'. The fast interface was called a KMC and would do
about 50K baud, asynchronous. I don't quite remember the name of the
slower interface or its speed, but maybe it did 9600 Bd.
On 9/10/22 5:13 PM, Robert Armstrong wrote:
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
A Tops-10
node appears to be able to have separate connections via a KDP, viz:
It's
not a TOPS-10 issue; it's a KS10/2020 limitation because Ethernet is not
supported on that machine. The KDP is actually a combination of one KDP and
one or more DUPs. Each DUP is a single synchronous line interface and you can
have up to four. They can be used for either DECnet or ANF10. I believe that
officially DECnet only supported one DUP line, but in practice you could have
more.
But on a KL10, of course, it's the same as for TOPS20 and normally you'd have
the NI20 Ethernet interface. But I'm pretty sure there was a DN-something
front end that supported synchronous DECnet circuits, so I would expect those
were possible too.
Bob
802
days inactive
804
days old
49 comments
14 participants
participants (14)
-
Brian Hechinger -
Dave McGuire -
David Moylan -
Johnny Billquist -
Mark Curtis -
Mark Matlock -
Paul Koning -
Peter Lothberg -
Robert Armstrong -
Supratim Sanyal -
Thomas DeBellis -
Tomas Prybil -
Trevor Warwick -
Wilm Boerhout