We are joining up with the North East of England: every repeater should add eng-ne, and sco-admin if it has not already. Why eng-ne · Why sco-admin

MeshCore in Scotland/Peers/Guidelines

Peering guidelines

Thinking of peering your MeshCore network with ScotMesh? This is the technical setup we recommend to protect both meshes. None of this is mandatory, but following it keeps peering stable for your network and ours.

Recommended, not required. You do not need every point below to peer. But each one protects both meshes from runaway traffic, and a peer that skips them is the first we throttle when things get busy. Treat this as the setup we would run ourselves.

How peering works

reciprocal, and scoped to a region

Every MeshCore network runs its own region. Ours is sco. Peering is reciprocal: you carry sco, we carry your region, and a message on a region both sides hold floods both meshes and stops at the edge. Nothing else crosses.

Watch it live (traffic coloured by region, and a step-by-step of what crosses and what does not) on the Peers page and its walkthrough.

Quick setup

paste this on each peer repeater, then read why below

# carry ScotMesh's region (never sco-admin)
region put sco
region allowf sco               # allow scoped sco flood traffic
region denyf *                  # refuse unscoped traffic
region default <your region>    # scope your adverts to your region
region put <your region>-admin  # private admin/bot region (we will not carry it)
region save                     # persist the region changes above
set path.hash.mode 2            # 3-byte paths: cap any flood at 21 hops
set loop.detect minimal         # enforce loop detection

region save persists the region table. set values persist on their own.

What we recommend

the seven settings above, and why each matters

Run 3-byte path hashes set path.hash.mode 2

A 3-byte path hash caps any flood at 21 hops and lets repeaters detect a packet that loops back and drop it. A 1-byte hash is ambiguous on a mesh this size: many nodes share a first byte, so a relay sends traffic bouncing between nodes it never touched. We run 3 bytes. Carry it across the border too.

Carry sco, never sco-admin

Add sco so ScotMesh traffic crosses into your mesh. Do not add sco-admin, as that is our internal management scope and stays inside ScotMesh. Carrying it pulls admin chatter onto your repeaters for no benefit.

Keep bot traffic on an admin region region put <your region>-admin

Give your own automated, flood-prone traffic its own region, for example <your region>-admin: map pollers, MeshMapper, status bots and management commands all live there. We will not carry it, so it stays inside your mesh and never floods across into ScotMesh. We were guilty of this ourselves. Read Keep Scotland's traffic in Scotland for how it bit us and how we fixed it.

Set every repeater's default region region default <your region>

Your repeaters should default-scope their own adverts to your region. Without a default region a repeater's adverts are unscoped, the rest of the mesh rejects them, and it never learns the node exists, so you get silent, shadow nodes that are on air but invisible.

Refuse unscoped traffic region denyf *

Deny unscoped wildcard forwarding on every repeater. Unscoped traffic cannot enter ScotMesh by design, and a repeater forwarding it anyway gets ignored by the compliant ones around it: herd immunity. Blocking it on your side keeps that flood off the air entirely.

Keep sco to direct peers only

The networks beyond you (your peers, who are not ours) must not add sco. Peering is one hop: we agree to carry each other's region, not to haul in everyone downstream of you. If your peers carry sco, their traffic floods into us through you, and that is exactly what makes a mesh fall over.

Enforce loop detection set loop.detect minimal

Keep loop detection on, at least at the minimum, across your repeaters. Combined with the 21-hop cap it stops a single message circling the two meshes and amplifying itself into an outage. It is a stored setting, so no region save.

Why peer by region

what you get for scoping it this way

No unscoped flood

Traffic with no region scope never crosses. Both meshes stay quiet except for the regions you agreed to share.

The peer, not the whole world

Your nodes advert into us and we see them; networks beyond you stay out. Chat still crosses on the shared region, so conversation flows without absorbing every neighbour.

Bounded and predictable

3-byte paths cap a flood at 21 hops and loop detection drops anything that circles back. A busy or misbehaving mesh reaches only so far.

Easy to dial back

Every repeater carries the region, but the few that bridge the meshes are the choke point. Cap the hops allowed there, or drop the region: a change of minutes, from either side.

Risks, and how we handle them

region peering is not free: here is the trade, and the mitigation

Risk

Cross-border traffic grows until it destabilises the mesh.

Mitigation

The 21-hop cap bounds how far any flood travels. At the border we cap the hop count we accept on a scoped packet. If not enough, we drop the region entirely.

Risk

Traffic from networks beyond your mesh leaks into ScotMesh through you.

Mitigation

Only direct peers carry sco. Your peers, who are not ours, must not add it, so their traffic stops at your edge, not ours.

Risk

Unscoped flood traffic swamps the air.

Mitigation

region denyf * refuses it on every compliant repeater; the ones that do not comply get herd immunity: their neighbours simply will not forward it.

Risk

A message loops between the two meshes and amplifies itself.

Mitigation

Loop detection is enforced, and the hop cap backs it up, so a looping packet is dropped, not repeated.

Risk

A repeater with no default region puts shadow nodes on air.

Mitigation

region default <your region> scopes its adverts so the mesh learns it properly instead of rejecting it.

If the mesh becomes unstable

a first line of defence, and how far we escalate

Once we are peered, we map out the strategic repeaters: the ones that bridge our meshes and the points traffic funnels through. They are our first line of defence: if a region starts to destabilise the mesh, they are where we add border protection. We work with the peer throughout, and escalate only as far as we have to.

  1. 1
    Locateimpact: low

    Work with the region

    First we get in touch with the peer and try to find and clear the interference quickly: a chatty node, a loop, or a misconfigured repeater. Most problems stop here.

  2. if not resolved
  3. 2
    Cap hopsimpact: guarded

    Limit flood hops at the border

    We turn down the maximum flood hop count on the strategic repeaters, to an appropriate limit (3 to 10 hops), so a distant flood dies before reaching the mesh.

    # on the strategic / border repeaters
    set flood.max 5        # pick 3-10: drops floods past this many hops

    set values persist on their own, so no region save is needed.

  4. still not resolved
  5. 3
    Pull the borderimpact: elevated

    Drop the region from strategic repeaters

    If capping hops is not enough, we temporarily stop carrying the peer's region on the strategic repeaters, closing the bridge at the choke points while the rest of the mesh runs normally.

    # on the strategic repeaters, temporarily
    region denyf <region>    # stop carrying the peer region here
    region save
  6. still not resolved
  7. 4
    Drop en masseimpact: high

    Drop the region across the mesh

    As a last resort we drop the region on repeaters en masse until the interference stops. The peering is paused, not ended. We bring it back once it is stable and the cause is understood.

    # on every repeater, until it settles
    region denyf <region>    # across the mesh
    region save
  8. still not resolved
  9. 5
    Throttleimpact: critical

    Throttle the border repeaters

    If even dropping the region does not clear it, we choke the strategic repeaters at the hardware level, cutting their duty cycle to 2% so they transmit almost nothing, until the interference stops.

    # on the border repeaters, last resort
    set dutycycle 2       # 2% airtime: throttles everything through them
We work with the peer as much as practical at every step, and you do the same to us. But protecting the mesh (ours and our other peers') comes first: a stable mesh is the whole point of peering carefully.

Who we peer with

kept deliberately small and local

We peer with direct neighbours (meshes whose coverage reaches ours) and occasionally a small network beyond a peer where it is the natural next hop, like the Isle of Man. Every link is two-way and limited to agreed regions: we carry yours, you carry sco, nothing else.

Carrying a region costs airtime on every repeater, so we add a peer only when it is a true neighbour. Current peers are on the Peers page.

Ready to peer?

If your network borders ours, or a peer's, come and say hello. We do not start any links until we have had a chat and we are both happy with it. If the community has already invited you, we go straight ahead and begin building them. Once the regions are agreed, peering is a quick change on both sides.