M17 Project Forum
A few notes about how to link reflectors - Printable Version

+- M17 Project Forum (https://forum.m17project.org)
+-- Forum: M17 (https://forum.m17project.org/forumdisplay.php?fid=3)
+--- Forum: Reflectors (https://forum.m17project.org/forumdisplay.php?fid=6)
+--- Thread: A few notes about how to link reflectors (/showthread.php?tid=58)

A few notes about how to link reflectors - n7tae - 11-10-2020

Mrefd uses a mesh model of interlinking developed by the xlxd team. First of all, any particular connection has to be configured on both ends of the connection. We'll call a collection of interconnected reflectors a group. The smallest possible group contains  two reflectors. Once the link is established, clients on one reflector can hear and be heard from clients on the other reflector.

A group can share multiple modules. If they do, traffic on one of the shared modules will not be heard by clients linked to the other modules in that group. A reflector may participate in multiple groups, but any given module can only be in a single group. Once a module is assigned to a group, it should never be configured to be in another group.

With larger groups, each reflector in the group must link to every other reflector in the group. Consider a group of three reflectors, M17-001, -002 and -003. Each reflector needs two entries in its mrefd.interlink file pointing to the two other reflectors in the group. Traffic is managed in this more complex group by a "one hop" policy. This policy prevents "looping" that might arise in the the older styled "train-car" linking. Here is how mesh linking works:

When a client on one of the group modules sends a voice stream to its reflector, the reflector sends it to all its linked clients, including other linked reflectors. However, the voice stream directed to another reflector is marked with an extra byte. When the receiving reflector gets this voice stream, it can easily identify that it is from a reflector and not a normal client so it will only pass the stream to its normal clients, not to other reflectors in the group! A stream is only relayed one time within a group.

If a group is missing a link in one of the connections, all clients on the group may not be able to hear everyone else on the group. Let's say in the example above M17-003 hasn't yet got around to configuring the link to -002. In that case clients on -001 will hear everyone, but clients on -002 won't hear clients on -003 and vis versa. That can be very confusing for clients listening to the group module. Administrators can usually easily tell if something is wrong by monitoring the mrefd logs, "sudo journalctl -u mrefd -f". If a link is only configured on one side, both sides of the link will see the attempted link fail, over and over again. See the attached file for an illustration of a good and bad four-way group.

Administrators that want to join an established group need to communicate with all of the current group members. It's also a good idea for group members to occasionally look at the dashboards of each of their group reflectors to be sure there aren't "dangling" members connected somewhere on the group.

RE: A few notes about how to link reflectors - n7tae - 12-20-2020

The XLX mesh grouping model used for M17-M17 interlinking has the best possible performance for any linking model and it also guarantees that looping problems will never arise from the linking topology. However, poorly executed shared groups won't work properly unless everyone in the shared group is linked to every other member in the group.

If you want to link a module (or multiple modules) with a single other reflector. It's pretty easy. You and the sysop of the other reflector just need to agree which modules are to be shared and then each of you can add the new line in your mrefd.interlink file.

However it gets more complicated if three or more reflectors want to share a module or a group of modules, so here is a proposed protocol for applying to become a member of an already established group. Here is a quick outline:

  1. An applicant emails all the current group members with a request.
  2. The current group members vote on the application.
  3. If approved everyone makes changes to their mrefd.interlink file to add the new member.
Now here is the details:

  1. The "applicant" new member emails ALL the members of the current shared group. He gets the email addresses of that group from the various dashboards of that group. In the email, he says something like "My name is <some name> and I am an admin of M17-XXX and I want to join your shared module(s) <module(s)>. M17-XXX has an IPv4 address of <x.x.x.x> and an IPv6 address of <xxxx:xxxx::xxx>. My reflector dashboard is at <some url>." It would be courteous to list the proposed changes to the applicant's mrefd.interlink file. That way the established members can make sure the application will work properly.
  2. Then the current members will vote on your application by doing a "reply all" to your message. Each one of those current members should look over your dashboard and make sure the request is reasonable. If any member has problems with the request, they can respond (again with a "reply all" email) outlining a concern or objection. In the case of a concern, then the applying member needs to resolve this concern. In the case of an objection, the process is done and the application is denied. Of course the applying member is welcome to rectify the objection and re-apply.
  3. Once the applicant had received approvals from everyone in the current group, he can once again email everyone in the current group. It would be easiest to once again remind everyone of the applicant's details: the reflector callsign, the IP address(es) of the reflector and which module is going to be shared. If the applicant's server is IPv6 capable, then some links may use that address instead of the IPv4 address.
As a shared group gets bigger this process will take more time. Everyone need to be patient. The applicant needs to wait on everyone in the group and resolve any problems that might arise. Likewise the existing group members must not "jump the gun" and establish the connection before everyone has voted. The existing group must also do their "due diligence" by making sure the applicant doesn't already have connections to the requested module, or there are other problems with the applicant's reflector. It's important to keep everyone up to date, so everyone should use the "reply all" when communicating about the new application.

If any current member strongly objects to the applicant for "personal reasons", then the group needs to come to a common solution. Either the applicant will be refused or the objecting current member may voluntarily remove his reflector from the group, allowing the new applicant in. Hopefully it will never come to this, but it might in some situations.

RE: A few notes about how to link reflectors - petar1 - 01-17-2021

Which port is used for interlink?

RE: A few notes about how to link reflectors - n7tae - 01-21-2021

(01-17-2021, 08:08 AM)petar1 Wrote: Which port is used for interlink?

UDP 17000