HECnet

hecnet@lists.dfupdate.se

15586 discussions

Request for comments on subdividing area 9

by b4＠gewt.net

On 8 Jan 2013, at 18:05, "Rob Jarratt" <robert.jarratt at ntlworld.com> wrote: Area routers should actually be at the top end of the range ie 9.1023 and down from there. That is because higher numbered nodes take priority over lower numbered ones with the same priority. That way if a rogue area router appears it won t take over the routing, unless deliberately configured to do so. Okay, I'll shift the administration/routing segment to 9.1000-9.1023 then. Regards Rob From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Cory Smelosky Sent: 08 January 2013 22:26 To: hecnet at Update.UU.SE Subject: [HECnet] Request for comments on subdividing area 9 Hello! The current way I allocate node numbers is in sequential order and it's getting tremendously messy and difficult to manage, so I am going to come up with a plan to divide things more cleanly and I'm looking for feedback. I'm thinking: 9.1-9.21 for administration/control purposes (area routers and so forth), subdividing the area in to geographic areas (areas of ~250 each initially, the others can be further subdivided as needed), and then subdividing those geographic regions by purpose. so: (apologies about this chart being absolutely atrocious and useless, it functioned largely as stress relief) 9.1-9.21 | V relief OHIO (9.22-9.271)-----|----------------|-------------------| | | | | | V V V V V (VMS) (PDP-11) (PDP-10) (OTHER) (WORKSTATION) 9. (22-.72) (73-123) (124-174) (175-225) (226-278) And repeat for other regions. Should I subdivide further? What could I use instead of OTHER? Should I break up the area differently? Further suggestions? Should I put physical hardware as a sub-sub-subdivision, its own tertiary level (in place of OTHER), or not differentiate them at all? Let me know your thoughts. -- Cory Smelosky http://gewt.net/ Personal stuff! http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.

12 years, 11 months

Request for comments on subdividing area 9

by robert.jarratt＠ntlworld.com

Area routers should actually be at the top end of the range ie 9.1023 and down from there. That is because higher numbered nodes take priority over lower numbered ones with the same priority. That way if a rogue area router appears it won t take over the routing, unless deliberately configured to do so. Regards Rob From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Cory Smelosky Sent: 08 January 2013 22:26 To: hecnet at Update.UU.SE Subject: [HECnet] Request for comments on subdividing area 9 Hello! The current way I allocate node numbers is in sequential order and it's getting tremendously messy and difficult to manage, so I am going to come up with a plan to divide things more cleanly and I'm looking for feedback. I'm thinking: 9.1-9.21 for administration/control purposes (area routers and so forth), subdividing the area in to geographic areas (areas of ~250 each initially, the others can be further subdivided as needed), and then subdividing those geographic regions by purpose. so: (apologies about this chart being absolutely atrocious and useless, it functioned largely as stress relief) 9.1-9.21 | V relief OHIO (9.22-9.271)-----|----------------|-------------------| | | | | | V V V V V (VMS) (PDP-11) (PDP-10) (OTHER) (WORKSTATION) 9. (22-.72) (73-123) (124-174) (175-225) (226-278) And repeat for other regions. Should I subdivide further? What could I use instead of OTHER? Should I break up the area differently? Further suggestions? Should I put physical hardware as a sub-sub-subdivision, its own tertiary level (in place of OTHER), or not differentiate them at all? Let me know your thoughts.

12 years, 11 months

Area 48.....

by robert.jarratt＠ntlworld.com

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian Hechinger Sent: 08 January 2013 14:25 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Area 48..... On 1/7/2013 4:26 PM, Rob Jarratt wrote: Because the one downside of the Cisco's is they don't speak NICE. It would be awesome if they did. And adding NICE is also something I was thinking of adding to the user mode router, but that is a bigger job than interoperating with Cisco I think. Regards I'd prefer NICE over cisco integration. :) It will probably be Easter when I get some time to spend on implementing NICE. But at the moment only I use the router and it still has a problem in slightly more complex configurations that I need to work on before it could sensibly be used more widely in any case, but if anyone wants to test it do give it a go. Regards Rob

12 years, 11 months

Request for comments on subdividing area 9

by b4＠gewt.net

On 8 Jan 2013, at 17:41, Ian McLaughlin <ian at platinum.net> wrote: Correct me if I'm wrong (which is likely), but doesn't DECnet (at least the Cisco variant) resolve routing ties between area routers by using the highest numbered one? Maybe your area routers should be at the top end of the address range? This Cisco document says "End systems send routing requests to a designated Level 1 router. The Level 1 router with the highest priority is elected to be the designated router. If two routers have the same priority, the one with the larger node number becomes the designated router. A router's priority can be manually configured to force it to become the designated router." http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr191… (please excuse me if I'm totally off base) My area routing is done via layer 2 VPN and a multinet tunnel meaning i'm using VMS, all areas would be bridged to that one router via VPN or further tunnels. No cisco gear involved so that's a non-issue as far as I can tell. Ian On 2013-01-08, at 2:26 PM, Cory Smelosky <b4 at gewt.net> wrote: Hello! The current way I allocate node numbers is in sequential order and it's getting tremendously messy and difficult to manage, so I am going to come up with a plan to divide things more cleanly and I'm looking for feedback. I'm thinking: 9.1-9.21 for administration/control purposes (area routers and so forth), subdividing the area in to geographic areas (areas of ~250 each initially, the others can be further subdivided as needed), and then subdividing those geographic regions by purpose. so: (apologies about this chart being absolutely atrocious and useless, it functioned largely as stress relief) 9.1-9.21 | V relief OHIO (9.22-9.271)-----|----------------|-------------------| | | | | | V V V V V (VMS) (PDP-11) (PDP-10) (OTHER) (WORKSTATION) 9. (22-.72) (73-123) (124-174) (175-225) (226-278) And repeat for other regions. Should I subdivide further? What could I use instead of OTHER? Should I break up the area differently? Further suggestions? Should I put physical hardware as a sub-sub-subdivision, its own tertiary level (in place of OTHER), or not differentiate them at all? Let me know your thoughts. --- Filter service subscribers can train this email as spam or not-spam here

12 years, 11 months

HECnet performance....

by mcguire＠neurotica.com

On 01/08/2013 05:38 PM, Brian Hechinger wrote: Set up a (cisco) tunnel to 130.238.19.60 (and tell me your side IP address). I think it's time to come up with something a little better to track all these. Thoughts? A subdomain under some related domain (perhaps <sub>.hecnet.update.uu.se?) with the tunnel endpoints as A records? -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

Request for comments on subdividing area 9

by ian＠platinum.net

Correct me if I'm wrong (which is likely), but doesn't DECnet (at least the Cisco variant) resolve routing ties between area routers by using the highest numbered one? Maybe your area routers should be at the top end of the address range? This Cisco document says "End systems send routing requests to a designated Level 1 router. The Level 1 router with the highest priority is elected to be the designated router. If two routers have the same priority, the one with the larger node number becomes the designated router. A router's priority can be manually configured to force it to become the designated router." http://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/tr191… (please excuse me if I'm totally off base) Ian On 2013-01-08, at 2:26 PM, Cory Smelosky <b4 at gewt.net> wrote: Hello! The current way I allocate node numbers is in sequential order and it's getting tremendously messy and difficult to manage, so I am going to come up with a plan to divide things more cleanly and I'm looking for feedback. I'm thinking: 9.1-9.21 for administration/control purposes (area routers and so forth), subdividing the area in to geographic areas (areas of ~250 each initially, the others can be further subdivided as needed), and then subdividing those geographic regions by purpose. so: (apologies about this chart being absolutely atrocious and useless, it functioned largely as stress relief) 9.1-9.21 | V relief OHIO (9.22-9.271)-----|----------------|-------------------| | | | | | V V V V V (VMS) (PDP-11) (PDP-10) (OTHER) (WORKSTATION) 9. (22-.72) (73-123) (124-174) (175-225) (226-278) And repeat for other regions. Should I subdivide further? What could I use instead of OTHER? Should I break up the area differently? Further suggestions? Should I put physical hardware as a sub-sub-subdivision, its own tertiary level (in place of OTHER), or not differentiate them at all? Let me know your thoughts. --- Filter service subscribers can train this email as spam or not-spam here

12 years, 11 months

Re: VMS sources

by robert.jarratt＠ntlworld.com

I have fiche from the 3.x era if I remember correctly. Regards Rob -----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Dave McGuire Sent: 08 January 2013 19:59 To: hecnet at Update.UU.SE Subject: Re: [HECnet] Re: VMS sources On 01/08/2013 02:55 PM, Cory Smelosky wrote: I've always wondered about VMS sources: how they are actually distributed today and how much space they take? Is a CD-ROM enough for everything? And in which format are they? Just simple text files in a bunch of directories or there is something fancier such as some cross references and indexes? They used to make source *listings* available on fiche; I have several sets of those. It's a stack of fiche maybe 3-4" thick. How old are these "listings"? I haven't looked at them in years, but I think I have at least 5.1 and 5.2, possibly 4.7. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

12 years, 11 months

HECnet performance....

by wonko＠4amlunch.net

On 1/8/2013 9:01 PM, Peter Lothberg wrote: Set up a (cisco) tunnel to 130.238.19.60 (and tell me your side IP address). I think it's time to come up with something a little better to track all these. Thoughts? -brian

12 years, 11 months

Request for comments on subdividing area 9

by b4＠gewt.net

Hello! The current way I allocate node numbers is in sequential order and it's getting tremendously messy and difficult to manage, so I am going to come up with a plan to divide things more cleanly and I'm looking for feedback. I'm thinking: 9.1-9.21 for administration/control purposes (area routers and so forth), subdividing the area in to geographic areas (areas of ~250 each initially, the others can be further subdivided as needed), and then subdividing those geographic regions by purpose. so: (apologies about this chart being absolutely atrocious and useless, it functioned largely as stress relief) 9.1-9.21 | V relief OHIO (9.22-9.271)-----|----------------|-------------------| | | | | | V V V V V (VMS) (PDP-11) (PDP-10) (OTHER) (WORKSTATION) 9. (22-.72) (73-123) (124-174) (175-225) (226-278) And repeat for other regions. Should I subdivide further? What could I use instead of OTHER? Should I break up the area differently? Further suggestions? Should I put physical hardware as a sub-sub-subdivision, its own tertiary level (in place of OTHER), or not differentiate them at all? Let me know your thoughts.

12 years, 11 months

Re: VMS sources

by Paul_Koning＠Dell.com

Speaking of copyright notices in DEC software... The standard one included this paragraph: ; THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT NOTICE ; AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT ; CORPORATION. DIGITAL EQUIPMENT CORPORATION ASSUMES NO RESPONSIBILITY ; FOR ANY ERRORS THAT MAY APPEAR IN THIS DOCUMENT. But I have a copy of a manual (the RSTS V4 kernel ODT manual), which seems to be really an internal document though I got it outside DEC, which has this spoof: THE MATERIAL INCLUDED IN THIS DOCUMENT, LIMITED TO BUT NOT INCLUDING, CONSTRUCTION SPEEDS AND OPERATING PURPOSES IS FOR INSTRUCTION TIMES ONLY. ALL SUCH CLAIM IS MATERIAL WITHOUT NOTICE, AND IS BOUND TO CHANGE THE SUBJECT. :-) paul

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet