HECnet January 2013

hecnet@lists.dfupdate.se

40 participants
1313 discussions

MOP vs. Cisco, was Re: [HECnet] _PROVISIONAL_ map of HECnet, courtesy largely of Brian H.

by mcguire＠neurotica.com

On 01/09/2013 10:49 AM, Brian Hechinger 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> Uhhh...HOLY CRAP! That works from outside my network?! Is it working because you specified the circuit which gave it a path, or because it gleaned the DECnet area/node address from the (changed-by-DECnet) MAC address? I'm guessing the latter. (Peter?) So, can I get a non-priv account? something standard that we can get others to add would be nice. Yes, maybe username "hecnet"? "Role" accounts are a horrifically bad idea in general, but I think one is called for in this case. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 10 months

maintaining data in DNS, was Re: [HECnet] HECnet performance....

by wonko＠4amlunch.net

On 1/9/2013 12:43 PM, Dave McGuire wrote: On 01/09/2013 10:50 AM, 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. You could do an AXFR query for the subdomain. ;) You need to setup zone transfer rights for that though, right? Did I ever tell you about how I implemented a linked list in TXT records back in '93? At one time, Digex' nameservers had the menus for all the local carry-out restaurants stored, item by item, in the nameserver. I wrote a little C program to traverse the linked lists and print out the menus. That's disturbing. And awesome. :) -brian

11 years, 10 months

maintaining data in DNS, was Re: [HECnet] HECnet performance....

by b4＠gewt.net

On 9 Jan 2013, at 12:43, Dave McGuire <mcguire at neurotica.com> wrote: On 01/09/2013 10:50 AM, 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. You could do an AXFR query for the subdomain. ;) Did I ever tell you about how I implemented a linked list in TXT records back in '93? At one time, Digex' nameservers had the menus for all the local carry-out restaurants stored, item by item, in the nameserver. I wrote a little C program to traverse the linked lists and print out the menus. That sounds like an approach /I/ would try. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 10 months

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

by mcguire＠neurotica.com

On 01/09/2013 10:08 AM, Cory Smelosky 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. I like the idea. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 10 months

maintaining data in DNS, was Re: [HECnet] HECnet performance....

by mcguire＠neurotica.com

On 01/09/2013 10:50 AM, 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. You could do an AXFR query for the subdomain. ;) Did I ever tell you about how I implemented a linked list in TXT records back in '93? At one time, Digex' nameservers had the menus for all the local carry-out restaurants stored, item by item, in the nameserver. I wrote a little C program to traverse the linked lists and print out the menus. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 10 months

HECnet performance....

by wonko＠4amlunch.net

On 1/9/2013 12:15 PM, Jordi Guillaumes i Pons wrote: McLaughlin <ian at platinum.net> va escriure: I'd just like to say Thank You to everyone on the network for giving us all this huge plaything that we all dreamed of playing with a quarter of a century ago :) I strongly second this!! The awesomeness of all of you is beyond my ability to express in English! Mine too, and english is my native language! :) -brian

11 years, 10 months

HECnet performance....

by jg＠jordi.guillaumes.name

McLaughlin <ian at platinum.net> va escriure: I'd just like to say Thank You to everyone on the network for giving us all this huge plaything that we all dreamed of playing with a quarter of a century ago :) I strongly second this!! The awesomeness of all of you is beyond my ability to express in English!

11 years, 10 months

HECnet performance....

by b4＠gewt.net

On 9 Jan 2013, at 12:04, Ian McLaughlin <ian at platinum.net> wrote: On 2013-01-09, at 8:44 AM, Johnny Billquist <bqt at softjar.se> wrote: 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 If this was a production network with large volumes of data travelling across it, careful selection of metrics would be very important for performance. However, what we have is an ad-hoc network with islands controlled by individuals. These individuals have differing skill levels, hardware collections, and requirements from the network. There is no 'backbone' provider or administrator, so the metrics end up being all over the place. I would like to identify what results in me having rather low FAL access speeds, however. I don't know if my network is misconfigured, or if it's just a result of using real hardware on a remote node. In my case, if I had a link to a US area, who also had a link to a second US area, I would want to take the path from the first to the second, instead of going through Sweden and back (although I'm sure Sweden is beautiful this time of year). Assigning a fixed cost to the path type doesn't take in to account the real latency of that path. What would be ideal is if the mapping project that is currently underway could show the metrics of the links (in both directions, because they could be assymetrical). If the map could also show relative geographical locations, that would also be a good proxy for latency estimates on links. That would be quite useful. But you know what? This is the fun part of Hecnet. None of us are doing this because it's a mission-critical network (for some of us, that's probably what our day jobs are anyway) - we're doing it because it's fun, and we can play with 'what-if' without breaking anything important. What are you talking about? HECnet is mission critical. ;) Sometimes the tone in here gets a little serious. I'd just like to say Thank You to everyone on the network for giving us all this huge plaything that we all dreamed of playing with a quarter of a century ago :) I'd like to thank everyone here as well, you've helped me learn a lot and given me something fun to play with. :) Ian -- Cory Smelosky http://gewt.net/ Personal stuff! http://gimme-sympathy.org/ My permanently-a-work-in-progress pet project.

11 years, 10 months

HECnet performance....

by ian＠platinum.net

On 2013-01-09, at 8:44 AM, Johnny Billquist <bqt at softjar.se> wrote: 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 If this was a production network with large volumes of data travelling across it, careful selection of metrics would be very important for performance. However, what we have is an ad-hoc network with islands controlled by individuals. These individuals have differing skill levels, hardware collections, and requirements from the network. There is no 'backbone' provider or administrator, so the metrics end up being all over the place. In my case, if I had a link to a US area, who also had a link to a second US area, I would want to take the path from the first to the second, instead of going through Sweden and back (although I'm sure Sweden is beautiful this time of year). Assigning a fixed cost to the path type doesn't take in to account the real latency of that path. What would be ideal is if the mapping project that is currently underway could show the metrics of the links (in both directions, because they could be assymetrical). If the map could also show relative geographical locations, that would also be a good proxy for latency estimates on links. But you know what? This is the fun part of Hecnet. None of us are doing this because it's a mission-critical network (for some of us, that's probably what our day jobs are anyway) - we're doing it because it's fun, and we can play with 'what-if' without breaking anything important. Sometimes the tone in here gets a little serious. I'd just like to say Thank You to everyone on the network for giving us all this huge plaything that we all dreamed of playing with a quarter of a century ago :) Ian

11 years, 10 months

HECnet performance....

by wonko＠4amlunch.net

On 1/9/2013 11:44 AM, Johnny Billquist wrote: 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. I was referring to the Cisco tunnel interface numbering, not path cost. You did address a question I had about that, however. :) I can make it configurable, but ultimately it might be easiest to choose a path cost that is most likely going to work for everyone. -brian -brian

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