HECnet January 2013

hecnet@lists.dfupdate.se

40 participants
1313 discussions

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

11 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

11 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

11 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

11 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

11 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

11 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

11 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

11 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, 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. With the lack of metrics working for real on the bridged ethernet, here is what hapens... stupi->sg1(cost1)-<bridge(cost1) Everyone else sees area 59 with cost 2 Johnny wan't to put the cisco in Uppsala in area 1, well, then all traffic to aread 59 will go through your box and the multine tunnel. Without proper metrics on the bridged ethernet, the best I can think of is that we use the bridged ethernet as primary and the multinet and cisco tunnels as secondary (backup) traffic paths for nodes that are multihomed. You need to change the cost to 10 for me to be able to turn the tunnel back up, as I have in practice infinite BW to Uppsala. -P

11 years, 10 months

Request for comments on subdividing area 9

by b4＠gewt.net

On 9 Jan 2013, at 07:56, Peter Lothberg <roll at Stupi.SE> 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. 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. 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. There'd only be one link to the rest of HECnet, everything else would connect to the primary area router. 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 -- Cory Smelosky http://gewt.net/ Personal stuff! http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.

11 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet January 2013