HECnet

hecnet@lists.dfupdate.se

2 participants
15583 discussions

_PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by wonko＠4amlunch.net

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

12 years, 10 months

HECnet performance....

by wonko＠4amlunch.net

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

12 years, 10 months

HECnet performance....

by jeep＠scshome.net

Peter, I was able to set the circuit cost to 10 remotely so you should be all set. -Steve ________________________________ From: owner-hecnet at Update.UU.SE on behalf of Peter Lothberg Sent: Wed 1/9/2013 09:37 To: hecnet at Update.UU.SE Cc: hecnet at Update.UU.SE Subject: RE: [HECnet] HECnet performance.... I'm now trying to get the Multinet links to 192.108.200.211 59.58 (STUPI) cleaned up and re_established,=20 right now only the link to Legato is working properly. SG1=20 had cost 1 on their side instead of 10.=20 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. -Steve Steve, In that case you are right, and as I said before, the problem is the bridged ethernet. Multinet nodes, could increese the cost on their Ethernets, but it only works one direction, as all the remote nodes has the same metric on their Ethernet towards you. In the SG1:: LEGATO:: case you can do the local optimization as the topology and other nodes on those locations may allow it, but it's not possible to do that in area 59, and especially not if the cisco box in uppsala is in area 1 talking to area 59 with a additional hop. I'm only asking you to set your cost on the multinet link to stupi:: to 10. -P

12 years, 10 months

subnet info, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by b4＠gewt.net

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

12 years, 10 months

subnet info, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by roll＠Stupi.SE

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

12 years, 10 months

_PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by roll＠Stupi.SE

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

12 years, 10 months

HECnet performance....

by jeep＠scshome.net

Peter, I will set the costs to 10 for STUPI:: when I get home late this evening. -Steve ________________________________ From: owner-hecnet at Update.UU.SE on behalf of Peter Lothberg Sent: Wed 1/9/2013 09:37 To: hecnet at Update.UU.SE Cc: hecnet at Update.UU.SE Subject: RE: [HECnet] HECnet performance.... I'm now trying to get the Multinet links to 192.108.200.211 59.58 (STUPI) cleaned up and re_established,=20 right now only the link to Legato is working properly. SG1=20 had cost 1 on their side instead of 10.=20 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. -Steve Steve, In that case you are right, and as I said before, the problem is the bridged ethernet. Multinet nodes, could increese the cost on their Ethernets, but it only works one direction, as all the remote nodes has the same metric on their Ethernet towards you. In the SG1:: LEGATO:: case you can do the local optimization as the topology and other nodes on those locations may allow it, but it's not possible to do that in area 59, and especially not if the cisco box in uppsala is in area 1 talking to area 59 with a additional hop. I'm only asking you to set your cost on the multinet link to stupi:: to 10. -P

12 years, 10 months

Request for comments on subdividing area 9

by b4＠gewt.net

On 9 Jan 2013, at 08:40, Peter Lothberg <roll at Stupi.SE> wrote: Why is it messy? Putting administrative info in addresses that are most likely network endpoints? I'd just feel more organised if I grouped systems a bit more. Once upon a time, I always asked myself "does this make the network faster or cheaper or both" when suggestions that involved work was made. -:) Well, I'd save time coming up with a free node and I'd stop forgetting certain nodes exist. ;) Which would make it cheaper time-wise and easier to manage. :) --P

12 years, 10 months

Request for comments on subdividing area 9

by roll＠Stupi.SE

Why is it messy? Putting administrative info in addresses that are most likely network endpoints? I'd just feel more organised if I grouped systems a bit more. Once upon a time, I always asked myself "does this make the network faster or cheaper or both" when suggestions that involved work was made. -:) --P

12 years, 10 months

HECnet performance....

by roll＠Stupi.SE

I'm now trying to get the Multinet links to 192.108.200.211 59.58 (STUPI) cleaned up and re_established,=20 right now only the link to Legato is working properly. SG1=20 had cost 1 on their side instead of 10.=20 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. -Steve Steve, In that case you are right, and as I said before, the problem is the bridged ethernet. Multinet nodes, could increese the cost on their Ethernets, but it only works one direction, as all the remote nodes has the same metric on their Ethernet towards you. In the SG1:: LEGATO:: case you can do the local optimization as the topology and other nodes on those locations may allow it, but it's not possible to do that in area 59, and especially not if the cisco box in uppsala is in area 1 talking to area 59 with a additional hop. I'm only asking you to set your cost on the multinet link to stupi:: to 10. -P

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet