HECnet

hecnet@lists.dfupdate.se

2 participants
15561 discussions

by wonko＠4amlunch.net

On 1/8/2013 9:09 PM, Paul_Koning at Dell.com wrote: Obviously you need a DECnet API for Python so you can talk NICE directly rather than have to chew through NCP output. Working on it...:-) Oh, that would be FANTASTIC. The output of NCP is.... not exactly simple to parse. :) -brian

12 years, 5 months

Data Collector

by Paul_Koning＠Dell.com

Obviously you need a DECnet API for Python so you can talk NICE directly rather than have to chew through NCP output. Working on it... :-) paul On Jan 8, 2013, at 8:38 PM, Brian Hechinger wrote: The data collector back-end has been re-written. It now does zero logic and just takes the data output of NCP and stuffs it into dictionaries. It then dumps them to files with pickle. Now to re-write the front end to process that data. Here's the data I collect so far: SHOW KNOWN CIRCUITS SHOW ADJ NODES SHOW EXEC CHAR Anything else anyone would like to see farmed, just let me know. -brian

12 years, 5 months

Data Collector

by jeep＠scshome.net

-----Original Message----- From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Brian Hechinger Sent: Tuesday, January 08, 2013 20:39 To: hecnet at Update.UU.SE Subject: [HECnet] Data Collector The data collector back-end has been re-written. It now does zero logic and just takes the data output of NCP and stuffs it into dictionaries. It then dumps them to files with pickle. Now to re-write the front end to process that data. Here's the data I collect so far: SHOW KNOWN CIRCUITS SHOW ADJ NODES SHOW EXEC CHAR Anything else anyone would like to see farmed, just let me know. -brian I like looking at "SHOW KNOWN AREAS". I use that as a starting place. -Steve

12 years, 5 months

Data Collector

by wonko＠4amlunch.net

The data collector back-end has been re-written. It now does zero logic and just takes the data output of NCP and stuffs it into dictionaries. It then dumps them to files with pickle. Now to re-write the front end to process that data. Here's the data I collect so far: SHOW KNOWN CIRCUITS SHOW ADJ NODES SHOW EXEC CHAR Anything else anyone would like to see farmed, just let me know. -brian

12 years, 5 months

Request for comments on subdividing area 9

by hvlems＠zonnet.nl

AFAIK you are correct. Which explains the node addresses for the area routers for areas 5 and 44. From: Ian McLaughlin <ian at platinum.net> Sender: owner-hecnet at Update.UU.SE Date: Tue, 8 Jan 2013 14:41:22 -0800 To: <hecnet at Update.UU.SE> ReplyTo: hecnet at Update.UU.SE Subject: Re: [HECnet] Request for comments on subdividing area 9 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, 5 months

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, 5 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, 5 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, 5 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, 5 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, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet