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