On 2013-01-09 17:19, Peter Lothberg wrote:
On 1/9/2013 1:59 PM, Peter Lothberg wrote:
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?)
Great mind think alike. :)
I had though pretty much exactly that.
If we are going to do that, however, we should decide on a range of
tunnels to use.
For example on my router, 0, 1 and 2 are DECnet tunnels, 3 is my IPv6
tunnel to HE and 4 is a DECnet tunnel.
Re-pushing the configs in this case would be ugly, so I think it would
be wise to say, tunnels X through Y are dedicated to auto-DECnet tunnels
so I can write cisco configs to deal with that appropriately.
I will write something. :)
-brian
If you knew the capability (what kind of tunnels) a node can support and you have
a fixed priority for in what order to chose, given two nodes you can automatically
determine the required tunnel type and don't need to encode it in to you global
description as it's a pair-wise local matter..... -:)
A big part of the general problem is that all these numbers are local for each end of connections, so that you can get very asymetrical setups.
Also, the metrics are set on the circuit, and not individual destinations. While this worked more or less ok for DEC back in the day, with the bridge, the cost of two different destinations over the same circuit could in reality be very different.
In the end, it boils down to a couple of things for tweaking the costs.
1. Preference of tunnel or bridge. If you prefer using the bridge, then just set the ethernet circuit cost lower than the tunnel. The tunnel can be either a multinet tunnel, or a tunnel on the cisco.
2. If the rest of your network isn't on the same ethernet as the bridge is, then you can use tweaks and control to your hearts content.
3. If the rest of your network don't have some other path out, then it don't matter if the ethernet circuit cost is high, so still feel free to tweak it as needed.
I think that you should be able to tweak the costs freely almost all the time, without any issues. However, you will sometimes not get the results you are looking for if the other end, and all intermediate nodes have also set their costs based on similar views as yours.
Johnny
On 1/9/2013 1:59 PM, Peter Lothberg wrote:
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?)
Great mind think alike. :)
I had though pretty much exactly that.
If we are going to do that, however, we should decide on a range of
tunnels to use.
For example on my router, 0, 1 and 2 are DECnet tunnels, 3 is my IPv6
tunnel to HE and 4 is a DECnet tunnel.
Re-pushing the configs in this case would be ugly, so I think it would
be wise to say, tunnels X through Y are dedicated to auto-DECnet tunnels
so I can write cisco configs to deal with that appropriately.
I will write something. :)
-brian
If you knew the capability (what kind of tunnels) a node can support and you have
a fixed priority for in what order to chose, given two nodes you can automatically
determine the required tunnel type and don't need to encode it in to you global
description as it's a pair-wise local matter..... -:)
-P
On 2013-01-09 14:01, Steve Davidson wrote:
-----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.
I should add that if SG1:: and LEGATO:: need to pass information, the
circuit costs favor the Multinet Tunnel links between the two major US
hubs. I would rather the Multinet Tunnel be used instead of using the
bridge link to Sweden and then back again.
I should probably just point out that there is no reason to set up the bridges to all be just connected to Update, and have everything travel through that one hub. The bridge works equally well with multiple hops. Although it does not work with a mesh, since it don't do any kind of spanning tree.
Johnny
On 1/9/2013 2:00 PM, Peter Lothberg wrote:
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..
If it comes down to needing to use SNMP I'd much prefer this than exposing SNMP over the internet.
-brian
On 1/8/2013 5:44 PM, Dave McGuire wrote:
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?
The problem here is that it isn't searchable. You need to know the A record name. It would be more useful for me to have it in a db.
-brian
On 1/8/2013 1:02 AM, Dave McGuire wrote:
...and like this from NCP under VMS:
NCP> connect node gw physical address <MAC address> via <circuit-name>
Note that the MAC address must have its octets delimited by colons
under Linux, and hyphens under VMS.
NCP>connect node gw physical address AA-00-04-00-01-F4 via ISA-0
Console connected (press CTRL/D when finished)
User Access Verification
Username:
NCP>
So, can I get a non-priv account? something standard that we can get others to add would be nice.
-brian
On 1/9/2013 10:08 AM, Cory Smelosky wrote:
On 9 Jan 2013, at 10:06, Peter Lothberg <roll at Stupi.SE> wrote:
Perhaps a centralized database that maintains per-NODE info, not
per-AREA info. Then that database could have a field that denotes the
point of administrative control that is responsible for each node.
Centralising the NODE info could solve a lot of problems and make data minin=
g easier. ;)
...a wiki.....
...to be perfectly honest, a HECnet wiki isn't too bad of an idea.
If it has a way to pull data from a DB, even better. :)
-brian
On 1/9/2013 3:58 PM, Peter Lothberg wrote:
Yeah more and more of us are using Ciscos to do this. We really need
to find a way around this issue that doesn't involve manual maintenance
of routing info.
You can get the decnet routing table out of the cisco with SNMP. Need
to agree on a comunity and a RO pw...
Which requires "out of band" IP access. While I'm not opposed to doing that, it would be really nifty if we could do this entirely within DECnet. :)
-brian
On 1/9/2013 1:59 PM, Peter Lothberg wrote:
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?)
Great mind think alike. :)
I had though pretty much exactly that.
If we are going to do that, however, we should decide on a range of tunnels to use.
For example on my router, 0, 1 and 2 are DECnet tunnels, 3 is my IPv6 tunnel to HE and 4 is a DECnet tunnel.
Re-pushing the configs in this case would be ugly, so I think it would be wise to say, tunnels X through Y are dedicated to auto-DECnet tunnels so I can write cisco configs to deal with that appropriately.
I will write something. :)
-brian