If no one else does I can once I finish getting things setup.
-brian
On Dec 22, 2011, at 12:45, Johnny Billquist <bqt at softjar.se> wrote:
On 2011-12-22 18.42, Marc Chametzky wrote:
Have anyone analyzed, or read any documentation on how the tunneling
is done? TCP or UDP? Any additional headers or data in the stream in
addition to the encapsulated DECnet packets?
The only thing I know (from configuring my firewall) is that they are
UDP packets on port 700. I haven't looked to see what's inside the
packets, though.
Interesting. Could anyone grab a bunch of frames with tcpdump and send to me?
Johnny
On 2011-12-22 18.42, Marc Chametzky wrote:
Have anyone analyzed, or read any documentation on how the tunneling
is done? TCP or UDP? Any additional headers or data in the stream in
addition to the encapsulated DECnet packets?
The only thing I know (from configuring my firewall) is that they are
UDP packets on port 700. I haven't looked to see what's inside the
packets, though.
Interesting. Could anyone grab a bunch of frames with tcpdump and send to me?
Johnny
Have anyone analyzed, or read any documentation on how the tunneling is done? TCP or UDP? Any additional headers or data in the stream in addition to the encapsulated DECnet packets?
The only thing I know (from configuring my firewall) is that they are UDP packets on port 700. I haven't looked to see what's inside the packets, though.
--Marc
Speaking of Multinet and DECnet-over-IP. I just got this crazy idea to implement DECnet-over-IP tunneling in RSX, and it would be fun to be compatible.
Have anyone analyzed, or read any documentation on how the tunneling is done? TCP or UDP? Any additional headers or data in the stream in addition to the encapsulated DECnet packets?
Johnny
Were you able to verify that the new address works? ...
Yes, with
$ mul sho/nosym
and I turned TCPAn on itself and circuit displayed correct node on
the other end :)
--
I can also confirm that this works. I'm well used to changing Multinet
interface ip addresses and other Multinet parameters on production systems
without rebooting so I was interested to try it. (The only reason I've ever
found for a reboot is to ensure the startup files have been reconfigured
correctly. I suspect this is why Process recommend it. If I liked rebooting
things, I'd get a PC)
I set up a DECnet-over-IP link between CEIRE and CHEKOV and turned off the
SVA-0 circuit on CHEKOV. I made sure that the only DECnet connectivity was
over the IP link. Then I changed CHEKOVs ip address, reconfigured
DECnet-over-IP and re-established the link. I was then able to SET HOST
across the link. No reboot required.
It took me a while because CHEKOV, my VAX 2000 would not co-operate. However,
after a good shaking, the RD54 spun up and it booted.
Regards,
Peter Coghlan.
BTP::PETER
Were you able to verify that the new address works? ...
Yes, with
$ mul sho/nosym
and I turned TCPAn on itself and circuit displayed correct node on
the other end :)
--
Regards, Rok
Rok,
Were you able to verify that the new address works? If I test this then
I will actually need one of the remote addresses to change. This is not
something I wish to ask of the two sites that currently make use of
dynamic-DNS. What I may do is setup one of my other machines with
Multinet and then move it to another of the static addresses here to see
what happens. That will take a bit more effort so it may have to wait
until the weekend.
Also, I can't remember if I wrote MultiWatch for V5.2, or V5.3 - it's
been in use that long... This could explain the difference. I just
don't remember. Maybe, Fred remembers - his site was the reason for the
procedure in the first place. Fred???
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Rok Vidmar
Sent: Thursday, December 22, 2011 11:07 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet Tunnel Links defined
I wonder if what I saw was VAX specific??? ...
No way for me to test now. As a bonus I found out that
$ multinet set/decnet/remote=new_IP_NAME/device=TCPAn:/connect
work as well as
$ multinet set/decnet/remote=new_IP_ADDR/device=TCPAn:/connect
--
Regards, Rok
I wonder if what I saw was VAX specific??? ...
No way for me to test now. As a bonus I found out that
$ multinet set/decnet/remote=new_IP_NAME/device=TCPAn:/connect
work as well as
$ multinet set/decnet/remote=new_IP_ADDR/device=TCPAn:/connect
--
Regards, Rok
Rok,
I wonder if what I saw was VAX specific??? I will try this later this evening so it has minimal impact.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rok Vidmar
Sent: Thursday, December 22, 2011 10:03 AM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet Tunnel Links defined
$ ncp set circ TCP-0-n sta off>> $ multinet set/decnet/remote=new_IP_addr/device=TCPAn:/connect>> $ ncp set circuit TCP-0-n state on cost 9 hello timer 300>
If I remember right Multinet caches the IP address and
does not flush it. Let's not forget that Process Software
does not support anything but a reboot!
My method works for me. Tested with MultiNet V5.3 on
FreeAXP OpenVMS V8.4.
--
Regards, Rok
$ ncp set circ TCP-0-n sta off>> $ multinet set/decnet/remote=new_IP_addr/device=TCPAn:/connect>> $ ncp set circuit TCP-0-n state on cost 9 hello timer 300>
If I remember right Multinet caches the IP address and
does not flush it. Let's not forget that Process Software
does not support anything but a reboot!
My method works for me. Tested with MultiNet V5.3 on
FreeAXP OpenVMS V8.4.
--
Regards, Rok
Johnny,
I would like you to reenable the bridge connection to Sampsa. It will
be interesting to see the changes in the routing once this has happened.
The current picture while quite impressive for SG1 clearly is not the
real story (picture).
CHIMPY is offline so it should not be in the picture until after Sampsa
gets back from Finland.
Thanks.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:49 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-21 20:05, Sampsa wrote:
BTW, bounced the router and bridge remotely (which I REALLY dislike
doing) but no use.
Is Johnny's side of the bridge running ok?
Sampsa, I disabled you a few days ago when your connection (well, the
adjacency to MIM= was going up and down every few minutes for about two
days. I really dislike having so big logs with just CHIMPY up and down
messages... :-)
Are you more stable now?
Johnny
Sampsa
On 21 Dec 2011, at 21:01, Steve Davidson wrote:
Peter,
Add an additional connection to Multinet for SG1. Use 69.21.253.230.
I
would set your costs (because you are an "end node") as follows:
GORVAX = 3 Shortest distance and high speed
SG1 = 5 Medium distance and medium speed
LEGATO> 5 Longest distance and slower speed
According to Sampsa, his bridge link is having issues (I have no
access
to that), and he is out of country, so connecting to SG1 is probably
a
great idea for now and won't hurt anything. SG1 like LEGATO is a
dedicated Multinet router. All it does is that one function.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Peter Lothberg
Sent: Wednesday, December 21, 2011 2:08 PM
To: hecnet at Update.UU.SE
Cc: hecnet at Update.UU.SE
Subject: RE: [HECnet] Multinet Tunnel Links defined
Steve:
Where are you located?
I'm everywhere, the Vaxen is in Stockholm, Sweden.
What is your IP address? I can add links to GORVAX and SG1 at any
time. If your IP address is dynamic, then SG1 will deal with that
automatically whereas GORVAX is a manual change.
192.108.200.211
It;s static.
-Peter
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Actually, we have booted DECservers across the bridge. This site has
done it several times in the past. I'm not sure about recently though.
I don't keep track of that anymore.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Thursday, December 22, 2011 4:22 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined - area 13
As everybody here knows, Decservers don't use decnet but needed an entry
in the ncp database for MOM to figure out where the software was to be
found. Later on LANCP was introduced for that purpose.
Since we're not exactly short of areas, let alone node addresses there's
no reason why we cannot reserve an area for them. OTOH I doubt we'll
boot a decserver across the bridges (perhaps Sampsa will try that). So
I'll keep my DS100 in area 44, it is 44.8 (ASTAAT, At).
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 04:11:10
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links
defined
On 2011-12-22 04:04, Steve Davidson wrote:
Two things:
First I would like to continue to reserve area 13. All the
documentation about DECserver management refers to it.
Could you point me to some of that documentation? I've not seen any of
it, and I don't really at all understand the point of even setting up
information in the nodename database for DECservers, which don't even
speak DECnet to begin with. (And I do have DECservers up and running, as
well as manuals...)
I know that, from a convenience point of view, you can use the name as a
short cut for specifying the MAC address and circuit, but having an area
reserved for such a simple detail seems excessive.
Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run
-
all very important features. If I remember correctly, LEGATO is the
same platform for the exact purpose. The only difference between my
Multnet "gateway" is that it can accommodate dynamic-DNS at the other
end.
Cool. I guess that platform should be enough to handle normal HECnet
traffic even if we grow some more.
How do you deal with dynamic IP addresses?
PS One more network is in the wings. You should be getting email
about
it soon enough if you have not already.
Nothing yet.
Johnny
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:58 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
Current list as of right now:
.ncp sho act are
Active areas summary as of 22-DEC-11 03:53:33
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
2 Reachable UNA-0 19.41 (SG1)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 6.1 (STAR69)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
44 Reachable UNA-0 44.21 (NIKKEL)
54 Reachable UNA-0 19.41 (SG1)
59 Reachable UNA-0 19.41 (SG1)
.
That is 14 areas, and I'm talking to one more guy who wants a new
area,
which would bring us to 15.
Anyone object to me giving him area 13? It was asked to be reserved
for
DECserver management, but I don't really see the point of having an
area
for that purpose. But if you can convince me... :-)
Also, SG1:: is quite a hub from the bridge point of view. Lots of
connections coming through there. Nice. :-) What type of machine is
it?
Johnny
On 2011-12-21 18:29, Steve Davidson wrote:
At the moment 13 areas are up and running - this list only show 10.
Hopefully sometime today we will be at 14. We're working on it! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Tuesday, December 20, 2011 5:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-20 22:34, Steve Davidson wrote:
I have defined (or redefined) tunnels for areas 3 and 6 for both
GORVAX:: and SG1::. These are effective immediately. Enjoy!
Cool. Area 3 is up according to MIM. Pretty...
.ncp sho act are
Active areas summary as of 20-DEC-11 23:42:41
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 19.41 (SG1)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Wed, 21 Dec 2011, Steve Davidson wrote:
addresses. Fred could probably provide more info on this. The email
also contains a report that provides some details that could be useful.
It has sure helped Fred and myself deal with "dynamic" changes! :-)
Which since time I have switched ISP's (went from DSL to the local cable co) and now my address, while dynamic, is much more stable. I don't believe I've received an email from Multiwatch yet since I have switched and that was somewhere in ?-April-2011
However that being said, when I was on DSL and the address changed for no apparent reason, Steve's process worked well. A few minutes of downtime and the circuit came back up by itself.
Fred
On 2011-12-22 11:45, hvlems at zonnet.nl wrote:
My comments on booting a decserver in combination with the ncp database are limited to VMS.
And fairly old versions of VMS. Of course RSX responds faster since it doesn't need/use that overhead.
I would not be surprised if this have stayed the same in newer versions. I would guess it is more tied to Phase IV VMS. I would not be surprised if lancp was a result of the fallout from phase V.
Yes, RSX have much less overhead than VMS, along with much less architecture overhead of PDP-11 compared to a VAX or Alpha. Can't really tell what the overhead of Itanium is, but I bet it is substantial. Running at GHz speed of course hides that pretty well... :-)
When Sampsa tried to boot his DS200 its load request messages showed up on my LAN. Nothing arrived in
time for the DS200 apparently. My uplink is fairly slow so that could be the cause.
The extra overhead of the uplink could be an issue, but not necessarily. We're talking about a single packet or two in each direction before the boot machine is decided. But I know that on a local ethernet segment, RSX machines normally boots the DECservers, even with VAX 4000 machines on the same segment.
That aside, a question Johnny. VMS and ncp will only service a load host request if the mac
address of the target host is registered and thus known. Does RSX service the request provided
it can locate the requested filename?
Yes, and no. :-)
The MOP boot request itself can hold a requested boot image file name. The request also contains the type of device. RSX will only handle boot requests from devices that it approves of. This is really silly, but the MOP boot server in RSX have a list of devices it accepts requests from. If the request pass that list, the server looks in the default directory for the file requested, and will server.
If you have registered the address in the node name database, you have also give a file name in that database. If no file name is in the boot request, it will use the file name in the database. If both names exist, I'm not sure which one it will use.
So, even if I have the boot image for a VXT1200, for instance, RSX will not boot it. The reason is, I think, that RSX supports both secondary and tertiary boot images, and there are some possibly odd things going on with secondary boot images (I really should check more things up here, but I think that for booting when both secondary and tertiary image is needed, the secondary image is calculated from the device type and fed, and then the tertiary image comes, which the secondary boot can handle). But almost nothing use those anyway, and for tertiary boot images, the device type is pretty much irrelevant. Oh well, another thing I'd like to fix one of these days...
It was not my intention to support a dedicated area, 13 or whichever. My point was
that decservers be kept in local areas. Given the way VMS, ultrix-32 and Tru64 respond that makes sense
I also think that for times when people do want to set up DECservers, or whatever, in their databases, it would make more sense to place them in the same area they have the rest of the stuff.
I have not checked in Tru64, but I didn't think Ultrix made such a connection. But thinking of it now, I have probably only ran lat, and never dnet on Ultrix...
Johnny
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 11:18:31
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined - area 13
On 2011-12-22 10:22, hvlems at zonnet.nl wrote:
As everybody here knows, Decservers don't use decnet but needed an entry in the ncp database for MOM to figure
out where the software was to be found. Later on LANCP was introduced for that purpose.
Actually not really true. Or maybe that is true for VMS then. It is not
true for RSX. RSX boots DECservers happily without any information in
the nodename database.
And you can also connect to the admin serial port with MOP without
having an entry in the nodename database.
Since we're not exactly short of areas, let alone node addresses there's no reason why we cannot reserve an area
for them. OTOH I doubt we'll boot a decserver across the bridges (perhaps Sampsa will try that). So I'll keep my
DS100 in area 44, it is 44.8 (ASTAAT, At).
We're not short on either, but we are definitely much closer to running
out of areas than node numbers. At the moment, we are standing at 28
allocated areas, soon to be atleast 29. That is close to 50%.
But I'll leave area 13 alone for now, to make you happy. :-)
And for your information, MIM regularly boots DECservers over the
bridge... Mine and Updates, but occasionally also others. And RSX
normally starts booting a DECserver before VMS have even started
thinking about the request. :-)
To quote a piece of the RSX kernel:
;+
; If we cannot process a clock interrupt within 10 seconds, we are
; no longer processing in real time, and we may as well become
; a VAX ... Call an end to this ... NOW!
;-
BGCK$A BF.SAN,BE.IDC,<FATAL> ;;; System massively confused
:-)
Johnny
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 04:11:10
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-22 04:04, Steve Davidson wrote:
Two things:
First I would like to continue to reserve area 13. All the
documentation about DECserver management refers to it.
Could you point me to some of that documentation? I've not seen any of
it, and I don't really at all understand the point of even setting up
information in the nodename database for DECservers, which don't even
speak DECnet to begin with. (And I do have DECservers up and running, as
well as manuals...)
I know that, from a convenience point of view, you can use the name as a
short cut for specifying the MAC address and circuit, but having an area
reserved for such a simple detail seems excessive.
Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run -
all very important features. If I remember correctly, LEGATO is the
same platform for the exact purpose. The only difference between my
Multnet "gateway" is that it can accommodate dynamic-DNS at the other
end.
Cool. I guess that platform should be enough to handle normal HECnet
traffic even if we grow some more.
How do you deal with dynamic IP addresses?
PS One more network is in the wings. You should be getting email about
it soon enough if you have not already.
Nothing yet.
Johnny
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:58 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
Current list as of right now:
.ncp sho act are
Active areas summary as of 22-DEC-11 03:53:33
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
2 Reachable UNA-0 19.41 (SG1)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 6.1 (STAR69)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
44 Reachable UNA-0 44.21 (NIKKEL)
54 Reachable UNA-0 19.41 (SG1)
59 Reachable UNA-0 19.41 (SG1)
.
That is 14 areas, and I'm talking to one more guy who wants a new area,
which would bring us to 15.
Anyone object to me giving him area 13? It was asked to be reserved for
DECserver management, but I don't really see the point of having an area
for that purpose. But if you can convince me... :-)
Also, SG1:: is quite a hub from the bridge point of view. Lots of
connections coming through there. Nice. :-) What type of machine is it?
Johnny
On 2011-12-21 18:29, Steve Davidson wrote:
At the moment 13 areas are up and running - this list only show 10.
Hopefully sometime today we will be at 14. We're working on it! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Tuesday, December 20, 2011 5:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-20 22:34, Steve Davidson wrote:
I have defined (or redefined) tunnels for areas 3 and 6 for both
GORVAX:: and SG1::. These are effective immediately. Enjoy!
Cool. Area 3 is up according to MIM. Pretty...
.ncp sho act are
Active areas summary as of 20-DEC-11 23:42:41
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 19.41 (SG1)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
My comments on booting a decserver in combination with the ncp database are limited to VMS. And fairly old versions of VMS. Of course RSX responds faster since it doesn't need/use that overhead.
When Sampsa tried to boot his DS200 its load request messages showed up on my LAN. Nothing arrived in time for the DS200 apparently. My uplink is fairly slow so that could be the cause.
That aside, a question Johnny. VMS and ncp will only service a load host request if the mac address of the target host is registered and thus known. Does RSX service the request provided it can locate the requested filename?
It was not my intention to support a dedicated area, 13 or whichever. My point was that decservers be kept in local areas. Given the way VMS, ultrix-32 and Tru64 respond that makes sense
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 11:18:31
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined - area 13
On 2011-12-22 10:22, hvlems at zonnet.nl wrote:
As everybody here knows, Decservers don't use decnet but needed an entry in the ncp database for MOM to figure
out where the software was to be found. Later on LANCP was introduced for that purpose.
Actually not really true. Or maybe that is true for VMS then. It is not
true for RSX. RSX boots DECservers happily without any information in
the nodename database.
And you can also connect to the admin serial port with MOP without
having an entry in the nodename database.
Since we're not exactly short of areas, let alone node addresses there's no reason why we cannot reserve an area
for them. OTOH I doubt we'll boot a decserver across the bridges (perhaps Sampsa will try that). So I'll keep my
DS100 in area 44, it is 44.8 (ASTAAT, At).
We're not short on either, but we are definitely much closer to running
out of areas than node numbers. At the moment, we are standing at 28
allocated areas, soon to be atleast 29. That is close to 50%.
But I'll leave area 13 alone for now, to make you happy. :-)
And for your information, MIM regularly boots DECservers over the
bridge... Mine and Updates, but occasionally also others. And RSX
normally starts booting a DECserver before VMS have even started
thinking about the request. :-)
To quote a piece of the RSX kernel:
;+
; If we cannot process a clock interrupt within 10 seconds, we are
; no longer processing in real time, and we may as well become
; a VAX ... Call an end to this ... NOW!
;-
BGCK$A BF.SAN,BE.IDC,<FATAL> ;;; System massively confused
:-)
Johnny
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 04:11:10
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-22 04:04, Steve Davidson wrote:
Two things:
First I would like to continue to reserve area 13. All the
documentation about DECserver management refers to it.
Could you point me to some of that documentation? I've not seen any of
it, and I don't really at all understand the point of even setting up
information in the nodename database for DECservers, which don't even
speak DECnet to begin with. (And I do have DECservers up and running, as
well as manuals...)
I know that, from a convenience point of view, you can use the name as a
short cut for specifying the MAC address and circuit, but having an area
reserved for such a simple detail seems excessive.
Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run -
all very important features. If I remember correctly, LEGATO is the
same platform for the exact purpose. The only difference between my
Multnet "gateway" is that it can accommodate dynamic-DNS at the other
end.
Cool. I guess that platform should be enough to handle normal HECnet
traffic even if we grow some more.
How do you deal with dynamic IP addresses?
PS One more network is in the wings. You should be getting email about
it soon enough if you have not already.
Nothing yet.
Johnny
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:58 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
Current list as of right now:
.ncp sho act are
Active areas summary as of 22-DEC-11 03:53:33
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
2 Reachable UNA-0 19.41 (SG1)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 6.1 (STAR69)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
44 Reachable UNA-0 44.21 (NIKKEL)
54 Reachable UNA-0 19.41 (SG1)
59 Reachable UNA-0 19.41 (SG1)
.
That is 14 areas, and I'm talking to one more guy who wants a new area,
which would bring us to 15.
Anyone object to me giving him area 13? It was asked to be reserved for
DECserver management, but I don't really see the point of having an area
for that purpose. But if you can convince me... :-)
Also, SG1:: is quite a hub from the bridge point of view. Lots of
connections coming through there. Nice. :-) What type of machine is it?
Johnny
On 2011-12-21 18:29, Steve Davidson wrote:
At the moment 13 areas are up and running - this list only show 10.
Hopefully sometime today we will be at 14. We're working on it! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Tuesday, December 20, 2011 5:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-20 22:34, Steve Davidson wrote:
I have defined (or redefined) tunnels for areas 3 and 6 for both
GORVAX:: and SG1::. These are effective immediately. Enjoy!
Cool. Area 3 is up according to MIM. Pretty...
.ncp sho act are
Active areas summary as of 20-DEC-11 23:42:41
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 19.41 (SG1)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2011-12-22 10:22, hvlems at zonnet.nl wrote:
As everybody here knows, Decservers don't use decnet but needed an entry in the ncp database for MOM to figure
out where the software was to be found. Later on LANCP was introduced for that purpose.
Actually not really true. Or maybe that is true for VMS then. It is not true for RSX. RSX boots DECservers happily without any information in the nodename database.
And you can also connect to the admin serial port with MOP without having an entry in the nodename database.
Since we're not exactly short of areas, let alone node addresses there's no reason why we cannot reserve an area
for them. OTOH I doubt we'll boot a decserver across the bridges (perhaps Sampsa will try that). So I'll keep my
DS100 in area 44, it is 44.8 (ASTAAT, At).
We're not short on either, but we are definitely much closer to running out of areas than node numbers. At the moment, we are standing at 28 allocated areas, soon to be atleast 29. That is close to 50%.
But I'll leave area 13 alone for now, to make you happy. :-)
And for your information, MIM regularly boots DECservers over the bridge... Mine and Updates, but occasionally also others. And RSX normally starts booting a DECserver before VMS have even started thinking about the request. :-)
To quote a piece of the RSX kernel:
;+
; If we cannot process a clock interrupt within 10 seconds, we are
; no longer processing in real time, and we may as well become
; a VAX ... Call an end to this ... NOW!
;-
BGCK$A BF.SAN,BE.IDC,<FATAL> ;;; System massively confused
:-)
Johnny
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 04:11:10
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-22 04:04, Steve Davidson wrote:
Two things:
First I would like to continue to reserve area 13. All the
documentation about DECserver management refers to it.
Could you point me to some of that documentation? I've not seen any of
it, and I don't really at all understand the point of even setting up
information in the nodename database for DECservers, which don't even
speak DECnet to begin with. (And I do have DECservers up and running, as
well as manuals...)
I know that, from a convenience point of view, you can use the name as a
short cut for specifying the MAC address and circuit, but having an area
reserved for such a simple detail seems excessive.
Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run -
all very important features. If I remember correctly, LEGATO is the
same platform for the exact purpose. The only difference between my
Multnet "gateway" is that it can accommodate dynamic-DNS at the other
end.
Cool. I guess that platform should be enough to handle normal HECnet
traffic even if we grow some more.
How do you deal with dynamic IP addresses?
PS One more network is in the wings. You should be getting email about
it soon enough if you have not already.
Nothing yet.
Johnny
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:58 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
Current list as of right now:
.ncp sho act are
Active areas summary as of 22-DEC-11 03:53:33
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
2 Reachable UNA-0 19.41 (SG1)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 6.1 (STAR69)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
44 Reachable UNA-0 44.21 (NIKKEL)
54 Reachable UNA-0 19.41 (SG1)
59 Reachable UNA-0 19.41 (SG1)
.
That is 14 areas, and I'm talking to one more guy who wants a new area,
which would bring us to 15.
Anyone object to me giving him area 13? It was asked to be reserved for
DECserver management, but I don't really see the point of having an area
for that purpose. But if you can convince me... :-)
Also, SG1:: is quite a hub from the bridge point of view. Lots of
connections coming through there. Nice. :-) What type of machine is it?
Johnny
On 2011-12-21 18:29, Steve Davidson wrote:
At the moment 13 areas are up and running - this list only show 10.
Hopefully sometime today we will be at 14. We're working on it! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Tuesday, December 20, 2011 5:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-20 22:34, Steve Davidson wrote:
I have defined (or redefined) tunnels for areas 3 and 6 for both
GORVAX:: and SG1::. These are effective immediately. Enjoy!
Cool. Area 3 is up according to MIM. Pretty...
.ncp sho act are
Active areas summary as of 20-DEC-11 23:42:41
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 19.41 (SG1)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
As everybody here knows, Decservers don't use decnet but needed an entry in the ncp database for MOM to figure out where the software was to be found. Later on LANCP was introduced for that purpose.
Since we're not exactly short of areas, let alone node addresses there's no reason why we cannot reserve an area for them. OTOH I doubt we'll boot a decserver across the bridges (perhaps Sampsa will try that). So I'll keep my DS100 in area 44, it is 44.8 (ASTAAT, At).
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 22 Dec 2011 04:11:10
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-22 04:04, Steve Davidson wrote:
Two things:
First I would like to continue to reserve area 13. All the
documentation about DECserver management refers to it.
Could you point me to some of that documentation? I've not seen any of
it, and I don't really at all understand the point of even setting up
information in the nodename database for DECservers, which don't even
speak DECnet to begin with. (And I do have DECservers up and running, as
well as manuals...)
I know that, from a convenience point of view, you can use the name as a
short cut for specifying the MAC address and circuit, but having an area
reserved for such a simple detail seems excessive.
Second SG1 is a VS4000/30 (VLC). It is small, quiet, and cheap to run -
all very important features. If I remember correctly, LEGATO is the
same platform for the exact purpose. The only difference between my
Multnet "gateway" is that it can accommodate dynamic-DNS at the other
end.
Cool. I guess that platform should be enough to handle normal HECnet
traffic even if we grow some more.
How do you deal with dynamic IP addresses?
PS One more network is in the wings. You should be getting email about
it soon enough if you have not already.
Nothing yet.
Johnny
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Wednesday, December 21, 2011 9:58 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
Current list as of right now:
.ncp sho act are
Active areas summary as of 22-DEC-11 03:53:33
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
2 Reachable UNA-0 19.41 (SG1)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 6.1 (STAR69)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
44 Reachable UNA-0 44.21 (NIKKEL)
54 Reachable UNA-0 19.41 (SG1)
59 Reachable UNA-0 19.41 (SG1)
.
That is 14 areas, and I'm talking to one more guy who wants a new area,
which would bring us to 15.
Anyone object to me giving him area 13? It was asked to be reserved for
DECserver management, but I don't really see the point of having an area
for that purpose. But if you can convince me... :-)
Also, SG1:: is quite a hub from the bridge point of view. Lots of
connections coming through there. Nice. :-) What type of machine is it?
Johnny
On 2011-12-21 18:29, Steve Davidson wrote:
At the moment 13 areas are up and running - this list only show 10.
Hopefully sometime today we will be at 14. We're working on it! :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Tuesday, December 20, 2011 5:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Multinet Tunnel Links defined
On 2011-12-20 22:34, Steve Davidson wrote:
I have defined (or redefined) tunnels for areas 3 and 6 for both
GORVAX:: and SG1::. These are effective immediately. Enjoy!
Cool. Area 3 is up according to MIM. Pretty...
.ncp sho act are
Active areas summary as of 20-DEC-11 23:42:41
Next
Area State Circuit Node
1 Reachable 1.13 (MIM)
3 Reachable UNA-0 19.41 (SG1)
4 Reachable UNA-0 4.249 (SLAVE)
6 Reachable UNA-0 19.41 (SG1)
8 Reachable UNA-0 19.41 (SG1)
11 Reachable UNA-0 11.2 (MAISA)
19 Reachable UNA-0 19.41 (SG1)
20 Reachable UNA-0 19.41 (SG1)
33 Reachable UNA-0 19.41 (SG1)
42 Reachable UNA-0 42.1 (CANADA)
.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Add an additional connection to Multinet for SG1. Use 69.21.253.230. I
would set your costs (because you are an "end node") as follows:
GORVAX = 3 Shortest distance and high speed
SG1 = 5 Medium distance and medium speed
LEGATO > 5 Longest distance and slower speed
It ended up being:
DECNET-CONFIG>show
Circuit Name IP Destination Cost HelloTimer
------------ --------------- ---- -----------
TCP-0-0 64.142.52.93 10 300
TCP-0-1 188.220.63.6 5 300
TCP-0-2 69.21.253.230 7 300
It;s actually a routing-IV node... -:)
My speed is limited by the Uvax2, not the network (well the dequna is
only 10Mbit...)
I have mentioned it before, but I also have a cisco router on the same
LAN that can do DECnet in IP the cisco way if anyone wan't to try.
Thanks! --P
NCP>sh know cir
Known Circuit Volatile Summary as of 22-DEC-2011 09:56:51
Circuit State Loopback Adjacent
Name Routing Node
QNA-0 on 59.11 (DIMMA)
QNA-0 59.10 (SOL)
QNA-1 on
TCP-0-0 on 2.1 (LEGATO)
TCP-0-1 on 8.400 (GORVAX)
NCP>tell gorvax sh known cir
Known Circuit Volatile Summary as of 22-DEC-2011 09:57:53
Circuit State Loopback Adjacent
Name Routing Node
QNA-0 on
TCP-0-19 on 19.41 (SG1)
TCP-0-2 on 2.1 (LEGATO)
TCP-0-3 on 3.171 (NUK1C)
TCP-0-33 on 33.14 (FRUGAL)
TCP-0-59 on 59.58 (STUPI)
TCP-0-6 on 6.134 (ROOSTA)
-Thanks--P
Just to let everyone know Area 6 and STAR69:: are back to operational status. I had a power outage a week or so ago and forgot STAR69:: when I powered everything back on owing to the fact it is currently hidden behind a Sun workstation.
Still it's back working again and my bridge is up and working.
Some sad news - since I was running on HECNET last time I lost COWBOX:: , my Cobalt Qube2/PDP-11 emulator - I think the mainboard or power brick is fragged :( I still have all the data on the hard disk so I need to hook it up to STAR69::'s host machine and pull the disk images and config off.
I have a plan to replace it (and then some) with a new project in 2012 which will hopefully result in the smallest, cheapest, most power efficient DEC network ever seen. I will post more plans nearer the time :)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
If I remember right Multinet caches the IP address and does not flush it. Let's not forget that Process Software does not support anything but a reboot!
It is not that big a hit. In the future the hit will be even less when I make some changes to the startups and the hardware.
So far I have not heard of any complaints when it reboots. I suspect that no one even notices... It really does amount to noise.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Rok Vidmar
Sent: Wednesday, December 21, 2011 11:15 PM
To: hecnet at update.uu.se
Subject: Re: [HECnet] Multinet Tunnel Links defined
I have written a DCL procedure that does IP address lookups at
predetermined (configurable) intervals. If it finds a mismatched IP
address it reconfigures the the TCP-0-n (where "n" is the area - in my
case) IP address and schedules a reboot.
To avoid reboot, did you try
$ ncp set circ TCP-0-n sta off
$ multinet set/decnet/remote=new_IP_addr/device=TCPAn:/connect
$ ncp set circuit TCP-0-n state on cost 9 hello timer 300
These commands execute without error. I have no means yet to test
if remote address gets really changed.
--
Regards, Rok
I'll never forget 'logging into' my hdds for the first time. :)
You've seen _Dark Star_ ?? The first time I talked to a DSSI drive, that
image of having an existential conversation with the smart bomb kept popping
into my head :-) Too bad the RFxx firmware guys couldn't find a way to
stick Eliza in there somehow....
Bob
I have written a DCL procedure that does IP address lookups at
predetermined (configurable) intervals. If it finds a mismatched IP
address it reconfigures the the TCP-0-n (where "n" is the area - in my
case) IP address and schedules a reboot.
To avoid reboot, did you try
$ ncp set circ TCP-0-n sta off
$ multinet set/decnet/remote=new_IP_addr/device=TCPAn:/connect
$ ncp set circuit TCP-0-n state on cost 9 hello timer 300
These commands execute without error. I have no means yet to test
if remote address gets really changed.
--
Regards, Rok
