You are here

Suggestions for network topology improvements needed

7 posts / 0 new
Last post
w6bi
w6bi's picture
Suggestions for network topology improvements needed


In Ventura County, our backbone is primarily made of Ubiquiti AirOS radios.  They link the AREDN nodes on 10 sites together via DtD (in a dedicated VLAN2).  The AirOS nodes look like a mesh network to the AREDN nodes with a path to each AirOS node, and all of them almost equal LQ/NLQ DtD links.
The issues with how the current implementation of OLSR handles route flapping lead to frequent periods where the mesh network is unusable due to routes failing back and forth between the various (virtual) paths on the backbone.

We've not been able to figure out how to configure AirOS to look like a star network instead of a mesh network for the AREDN nodes.  If someone could point us to any documentation on that we'd be grateful.  (And no, as much as we'd like to convert the backbone from Part 15 to Part 97, it's still carrying some commercial traffic).

As an alternative, we tried setting up a separate VLAN between two of the sites on the Part 15 link and tunneling two AREDN nodes between this.   However, we couldn't make it work, most likely because the node is only listening to VLAN2 for DtD broadcasts on VLAN2 (doh) and not on the different VLAN we set up between the two sites.   Again if anyone currently has any ideas on how to implement this approach, we'd appreciate them!

Here's our current network mess.  Every AREDN node shown thinks it has a link to each of the Part 15 radios:




Thanks in advance

Orv W6BI

kc8ufv
kc8ufv's picture
As I understand it, DtD link
As I understand it, DtD link is designed for a direct connection with no cost. By having an SSID share that, they're going to look like a mesh. If you want it to behave like hub and spoke, instead of sharing the DtD link vlan, set up a mode at the hub location, and set up tunnels to the remote nodes. This will force traffic to take that specific route on the part 15 network.
AE6XE
AE6XE's picture
Suggest changing the part 15
Suggest changing the part 15 vlan used for the mesh network to not propagate over the entire network of  sites (which has to happen for every mesh node in the system to directly see each other).  Broadcast packets are traversing the entire system.   Put in a unique vlan for each P2P link, then let the mesh nodes figure out the routing.

Joe AE6XE
w6bi
w6bi's picture
VLAN Configuration?
Joe, since the OLSR broadcast packets use only VLAN 2, how can we configure unique VLANs for each true physical link in the Part 15 network?  Please expound!
Thanks.
Orv W6BI
AE6XE
AE6XE's picture
Access Control Lists?
I don't know what kind of switches are in use, but have a look at the Cisco Access Control List (ACL).  See this ref:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/xe-3s/sec-data-acl-xe-3s-book/sec-access-list-ov.html#GUID-98EA0035-DDC6-4F08-8567-C5E100C02F03

Basically, restrict the traffic at a tower site such that all the mesh nodes can directly communicate with each other on the switch on vlan 2, with no restrictions.   However, only one designated mesh node's traffic-interface will be allowed to go to/from a given part 15's P2P interface-link still on vlan2.    Continue on, another mesh node is designated to communicate out another part 15 P2P link-interface, etc. 

Joe AE6XE
w6bi
w6bi's picture
ACLs
They're Ubiquiti EdgeSwitches.  We'll investigate ACLs.
Thanks.
Orv W6BI
K6CCC
K6CCC's picture
That is largely the same

That is largely the same concept as what I suggested on MatterMost a few days ago, except Joe suggested using the ACL whereas I suggested using the port isolation table.  Both methods should work provided the switches being used have that capability - and I've never used a Ubiquiti switch, so don't know their capability.
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer