-----Original Message-----
From: owner-hecnet at Update.UU.SE
[mailto:owner-hecnet at Update.UU.SE] On Behalf Of Peter Lothberg
Sent: Wednesday, January 09, 2013 08:49
To: hecnet at Update.UU.SE
Cc: hecnet at Update.UU.SE
Subject: Re: [HECnet] HECnet performance....
Peter,
Everything is now set up on my end. I now have 3 Cisco
tunnels. The
= metric is 10 on all of them.
Change the metrics to match my side:
Tunnel2 Cost 10
tunnel to 192.108.200.213 Cost 20
tunnel to 199.0.131.2 Cost 20
The majority of areas now route through you according to my router:
Given that we have no way of setting metrics on the "bridged ethernet"
links, this is the best we can do that works in the general case.
I'm now trying to get the Multinet links to
192.108.200.211 59.58 (STUPI) cleaned up and re_established,
right now only the link to Legato is working properly. SG1
had cost 1 on their side instead of 10.
On VMS systems anyway, LAN circuit costs are set to 4 by default. I
always set Multinet circuit costs to 1 or 2 depending on whether it is
the preferred route or the alternate route. I would prefer to favor the
Multinet Tunnel circuits over the bridge links. They can be anywhere
between 4-10 times faster for file copy operations.
This is why SG1:: circuit costs are "1" in your case.
-Steve
Anyone else who want a cisco or Multinet HECnet tunnel set up?
-P
Peter,
Everything is now set up on my end. I now have 3 Cisco tunnels. The =
metric is 10 on all of them.
Change the metrics to match my side:
Tunnel2 Cost 10
tunnel to 192.108.200.213 Cost 20
tunnel to 199.0.131.2 Cost 20
The majority of areas now route through you according to my router:
Given that we have no way of setting metrics on the "bridged ethernet"
links, this is the best we can do that works in the general case.
I'm now trying to get the Multinet links to
192.108.200.211 59.58 (STUPI) cleaned up and re_established, right now
only the link to Legato is working properly. SG1 had cost 1 on their
side instead of 10.
Anyone else who want a cisco or Multinet HECnet tunnel set up?
-P
-----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 21:54
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Data Collector
On 1/8/2013 9:03 PM, Steve Davidson wrote:
I like looking at "SHOW KNOWN AREAS". I use that as a
starting place.
That should be simple enough to do.
-brian
I forgot to add that I always start with:
MCR NCP TELL MIM SHOW KNOWN AREAS
Then I walk the tree to see what comes back.
-Steve
On 1/8/2013 9:03 PM, Steve Davidson wrote:
I like looking at "SHOW KNOWN AREAS". I use that as a starting place.
That should be simple enough to do.
-brian
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.
