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
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
-----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
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
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
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.
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.
-----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
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
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
