This is an email I sent out to the Southern California HamNet mailing list.
The SoCal ham network has grown way beyond our expectations and continues to grow. We're likely pushing the OLSR routing
software far beyond what its authors expected for OLSR1. It does fairly well, but we suspect large multi-hop routing
loops as one of the issues it can't handle.
Those large routing loops are only possible when tunnels are used. They're being used far more and far beyond what
AREDN originally contemplated. But they're here and we have to deal with them.
So to ensure maximum network robustness we're adopting these guidelines for new tunnels within and leaving Ventura County:
- Suitable hardware (no 32 MB RAM devices).
- Current software.
- If there are nodes beyond your end of a (requested new) tunnel, they have to meet the same criteria.
- If after the tunnel is up you want to extend your local network via another tunnel, the same criteria need to apply AND we need to be notified first.
- In case of network issues we reserve the right to drop any tunnel without warning to ensure network stability and/or for troubleshooting.
We went back and audited existing tunnels to those criteria, too.
We can't mandate those guidelines regionally, but we strongly encourage anyone managing either end of a tunnel
to think hard about what you'll be adding (or have already added) to an already fragile network.
Your network (and every mesher within 20 hops of you) will thank you!
---------------------------------------------
Those guidelines were developed with the concurrence of local hams who administer large chunks of AREDN network in their area of Southern California (who are also going to work towards compliance with them). And we've received feedback that SFWEM (San Francisco Wires Emergency Mesh) is also considering adopting these guidelines.
Your thoughts?
73
Orv W6BI
"Those large routing loops are only possible when tunnels are used. They're being used far more and far beyond what AREDN originally contemplated."
I have posted this (below) in different forms here before, but I think it should be considered here again in regard to tying different mesh islands together with tunnels:
~~~~~
I have noted that there are some minor exceptions where a properly setup tunnel does NOT act the same as a normal AREDN RF link between devices. One example is MeshChat, where two devices hosting the same MeshChat "zone" will not update each other when connected thru a tunnel.
[opinion] As an aside, (while this can be a contentious issue) please also note that our local [informal, non-chartered] LVmesh (Las Vegas) group has in the past actively discouraged any use of "tunnels" except in the case of 1) emergencies; 2) limited appropriate community-support events; and/or 3) proper control operator functions limited to a temporary single end-point connection. The consensus was that we do NOT approve of remote mesh islands (big or small) connected by tunnels to our local RF mesh. (I have not been active in LV mesh for the last few months so this may have changed down there ... It is definitely the policy here in our local Idaho mesh island up here in the mountains.)
With all that said, a tunnel is a fantastic [temporary] tool for remote control operator support functions on a case-by-case basis. I install one on every remote node which has another network "back door", just in case. Thanks to those who implemented this feature, I just wish it wasn't sometimes seen as a way to generally tie remote bits together when RF doesn't do the job. [/opinion]
- Don - AA7AU
For another thread just started about MeshChat possibly not working thru tunnels (as I mentioned above), please see: https://www.arednmesh.org/content/meshchat-usb150
Please make all comments there in that thread about this specific issue.
Once again, apologies on side-tracking this topic, hope to see further discussion here about "Managing Large Networks".
- Don - AA7AU