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
We are not limited to route DECnet packets, we could turn on IP on the
tunnels, and CLNP/Phase5..
--P
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?
Build a tool that takes requests and generates configs (full mesh) and
pushes them to the routers.
(maybe we can have the router configs in a wiki?)
-P
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.
Why is it messy? Putting administrative info in addresses that are
most likely network endpoints?
If we at some time in the future want to get the routing optimal there
is one limitation to remember. There is no topology information shared
between areas, so if a node in area 1 want's to talk to a node in
area 2 and there are more than one link from area 1 to area 2 it will
pick the best (metric or router id) link to area 2, and it has no
information about what area router in area 2 is closest to the
destination node.
An optimal HECnet has metrics (costs on links) and all nodes in the
same area..... Or one area is basically connecting all it's area
routers with for practical purposes infinite bandwidth.
--P
-----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
