TRILL Switching for WISPs, Part 1
Ignitenet Meshlinq — 5-port TRILL-capable POE switch
TRILL (TRansparent Interconnection of Lots of Links) was created as a successor to spanning tree (STP) — like spanning tree, it's a method of creating loop-free network topology.
But unlike STP, TRILL can use all available bandwidth and links between a pair of nodes. By contrast, STP generates a loop-free network by automatically disabling redundant links, reducing the total bandwidth available.
I'm aware that TRILL never took off in the data center, superseded by technologies like VXLAN and EVPN. However, these technologies share in common the creation of a Layer 2 "overlay" on top of a Layer 3 underlay — taking the best features of routing (loop-free, deterministic paths) and combining it with bridging (host-to-host communication with no extra configuration required).
TRILL failed to scale up in a world where it needed to support hundreds of thousands of devices (virtual machines, in the eventual case) over a large network fabric.
In the context of WISP design, however, very few WISPs have hundreds of thousands of connected nodes in a given network. TRILL just might work, I thought to myself. The average WISP has fewer than 1000 customers; let's assume a maximum of three MAC addresses per customer required, and that's well within the scope of even a modest CPU running TRILL.
Prior to the introduction of the Meshlinq switch, it was only possible to run TRILL on "big" switches — 24 ports and up. For a small solar site, the power budget — and likely the customer base — required for big switches make for a discouraging ROI.
In part 2, I'll talk about my experiences testing the Ignitenet Meshlinq switches with a variety of backhauls, and what TRILL is good for. We'll look at both bench tests and real-world deployment.
In part 3, I'll talk about use cases where TRILL is not the right choice.
Stick around!