I can't find any documentation on how AREDN handles a mesh network with multiple nodes that have shared WAN connections. How does AREDN route traffic destined for the WAN when there is more than one possible egress? The scenario is that we will have a local, higher-speed connection that we want to be our primary connection. E.g. all traffic should be sent there and no need for balancing. Our other connection has much lower bandwidth, but it is using entirely different back-end infrastructure and should work if the primary fails. So really, we just need a fallback. We may have more nodes in the future with WAN connections, but just 2 in the near term. I have not dug into OSLR (some LSR experience from long ago) but we'd like to not bias the selection of the route to the WAN node, but do want to weight the WAN egress points themselves. Is this possible?
Thanks,
Rob KG7LMI
You are here
multiple shared WAN connections
Mon, 07/25/2022 - 23:40
#1
KG7LMI
multiple shared WAN connections
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Hi, Rob:
I am assuming that, in your note, all 'WAN' can be replaced with 'the internet' without changing the meaning.
Else, please further describe your 'WAN'.
Also, if "all traffic should be sent there", why use AREDN...which uses OLSR ?
What does AREDN firmware provide for you that is not already available in the device manufacturer's OS?
73, Chuck
Chuck,
I was trying to avoid supplying unnecessary context for my question, but I guess I should have provided some. My bad. So let me over-correct and provide too much context now ;-)
We are building an AREDN-based emergency communications network for Yavapai County AZ. The purpose of this network, the YC-ECN, is to supply backup communications to public service agencies, hospitals, the Office of Emergency Management, and other volunteer disaster service agencies through our combined county ARES/RACES group. Our county is mostly rural in nature, so an additional objective is to provide coverage in an incident for areas that lack cellular services. Building this network has and will take years due to the logistics of mountaintop tower politics, but eventually will cover the most populous portions of the county and the areas most prone to wildfires (see screenshot of Ubiquiti ISP planning tool). Most of the key backbone locations and about 1/2 of the key distribution (sector antenna) locations will be provisioned by the end of 2022.
While most of the traffic in an incident will be on-net, there is also the need to go off-net (e.g. Internet) to reach outside agencies. So, when I say "all traffic" I mean "all Internet traffic" which is a minority subset of the total traffic. Currently, we are planning for 2 such Internet gateways. (In commercial terms, I would call these gateways peering points.) One is in the county and uses commercial infrastructure in the county, but given our location, the fiber backbone from Phoenix is not the most extensive or robust and has failed multiple times in the past years. Therefore, a second location exists outside the county and connects directly to Phoenix which bypasses this fiber backbone. The in-county Internet gateway will go to an ISP and have significant bandwidth. The out-of-county connection goes to a WISP and is significantly slower and due to topological issues, we lose even more getting it across the county. So, if the ISP connection is up, we want the Internet traffic to go there, and if it is down, we want the Internet traffic to go to the WISP connection.
I am familiar with OSPF, and I am unfamiliar with the specifics of OLSR, but link state routing schemes in general have link costs/weights to converge on a topology. What I am asking is how I can weight the WAN/Internet gateway itself to cause one to be used and not the other without affecting the selection of the path to the gateway nodes themselves. In other words, I want to only affect the path of traffic with an off-net (e.g. Internet) ingress/egress and not any on-net traffic.
Up to now, our network has not been complex enough for me to worry about which path OLSR selects as there has never been a choice before. Now, we have multiple paths and I find the need to learn more about the details of OLSR, but have not found a reference. If someone can answer this question, that would be wonderful, but even better would be some references for me to learn more about how to configure OLSR in AREDN.
Finally, I am actually quite experienced with AREDN, as I started building this network in 2017 but there was a long pause while we switched gears to grant funding, which we completed last year. I post very infrequently, so I'm sure I am not familiar to you, but I am greatly appreciative of what the AREDN organization has done and continues to do to promote amateur radio data networking. We could not do this without you!
Hope that helps!
73, Rob
Between "We are building an AREDN-based emergency communications network for Yavapai County AZ. "
and "we want the Internet traffic to go to the WISP connection.",
I read, "We are providing backup internet access to 'public service agencies, hospitals, the Office of Emergency Management, and other volunteer disaster service agencies ' ".
I am not seeing any Amateur Radio services mentioned...only internet access is mentioned.
This is similar to the communications we already have had for several years.
We asked a local County ARES group: "What can we do for you?"
They said "We want backup internet access and backup telephone service."
We already had a network, so the first part only required one of our high-profile
home stations to enable 'Allow others to us my WAN' and reboot.
For the second part we established a PBX with 2 PSTN accounts.
Extensions on the local network can call each other,
can place an outbound call via PSTN,
can receive an inbound call from the PSTN.
We offered an AREDN node and IP telephone for their EOC.
We told the local County ARES that we had met their request.
They replied: "No, thanks, we have 'first net' now."
Since you seem to be describing a network with a single purpose (internet access),
I wonder why you are using AREDN and not the manufacturer's built-in OS.
+1 K6CCC
Your control of routing is rather restricted using AREDN firmware.
73, Chuck
Again, no, it is not Internet-only in any way and we considered WISP gear years ago before starting this and decided to go this way. The reasons are not pertinent here.
See my new post below - looks like this is a dead end.
73, Rob
It seems to me that, for reasons presented in #6 https://www.arednmesh.org/comment/19876#comment-19876,
and the limitations of OLSRv1,
AREDN firmware is not suitable for the automatic failover of ISP connections.
It seems to me that the outdoor rated devices in the 'Supported Platform Matrix'
are WISP equipment.
73, Chuck
I have no inside knowledge, but I would assume that the node routing knows absolutely nothing beyond the last AREDN node - other than the presence of an allowed internet connection. With that assumption, the nodes trying to get to the internet are simply going to route based on lowest routing cost (ETX). In other words, it will route via the AREDN network to whichever node that is providing internet access has the lowest ETX - and completely ignore the speed of that intenet connection.
BTW with that said, I am a strong believer that except in a dire emergency, users should not be getting to the internet via the AREDN mesh at all.
Thanks, Darryl. Searching for that term led me to some other sites with more info on OLSR that I need to explore further.
Can you give me some background on the version of OLSR used in AREDN? I've found several OLSR repos. However, I see there is an OLSR package in OpenWRT, so I assume that is what is used in AREDN?
It may be time for me to start looking through the AREDN and (OpenWRT) source code!
Thanks.
73, Rob
Thanks!
73, Rob
Route Calculation
The proposed heuristic for route calculation in RFC3626 is a relatively trivial shortest-path algorithm. It can be outlined as:
1. Add all one hop neighbors registered as symmetric to the routing table with a hop-count of 1.
2. For each symmetric one-hop neighbor, add all two-hop neighbors registered on that neighbor that has:
* Not already been added to the routing table.
* A symmetric link to the neighbor.
These entries are added with a hop-count of two and next-hop as the current neighbor.
3. Then, for every added node N in the routing table with hop-count n = 2 add all entries from the TC set where:
* the originator in the TC entry == N
* the destination has not already been added to the routing table
New entries are added with a hop-count of n + 1 and next-hop as the next-hop registered on N's routing entry.
4. Increase n with one and do step 3 over until there are no entries in the routing table with hop-count == n + 1
I had assumed there was a coefficient I could change that would affect how the directed graph of all nodes would be translated into routing decisions, but it looks like there is not. There is a lot of research work on overcoming this and other shortcomings of OLSR, so maybe some time in the future this will be possible. Please let me know if I am missing something, but for now, it's probably time to bail on this. Oh well, at least I learned a lot about how OLSR works, so that's something ...
73, Rob
Orv W6BI
73, Rob