An olive grove outside Chania, three days, 3,000 people a day, two stages, a food court with twenty vendors, and not a single cable in the ground. Everything arrives in cases on Monday, goes live on Thursday, and is gone by Sunday night. We build it on MikroTik in 10 tested steps, from the NOC tent outwards to two Starlinks and a 5G line, and finish with a teardown that leaves no passwords behind.
Full network · all steps built
highlighted = lines added in the selected step · earlier steps shown plain · later steps hidden
This is part 7 of the Build series, and the first network that's designed to be thrown away. Every other Build assumes a building, cable runs and years of service. A festival has a field, a generator and four days. That changes what "good design" means: everything is pre-built and tested in the workshop, every link is a radio or a single armoured fibre, every node runs on generator power with a battery to ride through switchovers, and the most important feature of the network is that the gates keep scanning tickets even when it fails.
01
A fictional but realistic mid-sized festival. The organiser's only firm requirement: "the gates and the bars can't stop".
Attendees enter through two gates where 12 handheld scanners check QR tickets against the ticketing company's cloud. The food court has 20 vendors with card terminals and tablet tills, and a charging area where people actually sit down with their phones. The main stage streams a live feed, and a press tent has wired desks for journalists. Staff, security and first aid use tablets. There's no fixed infrastructure: power comes from generators, and the site is 300 m across with olive trees in every line of sight.
| Requirement | Where it comes from, and what it forces |
|---|---|
| R1 Gates never stop | A queue of 2,000 people at opening time can't wait for a network. Scanners validate online but keep working offline, and the gates' link is the most protected in the design. |
| R2 Bars never stop | Twenty tills taking cards. Payments are isolated, prioritised, and fail over to 5G. |
| R3 The stream never stutters | A live stream needs steady upload. It gets its own Starlink, not a share of one. |
| R4 Public Wi-Fi where it matters | Free Wi-Fi in the food court and charging area only, 2 Mb/s per phone, isolated, sized for well over a thousand devices at once. |
| R5 Build in a day, tear down in hours | Every node is pre-configured and labelled in the workshop; installation is mounting and plugging in. |
| R6 Survive the field | Generators switch over, trucks park in radio paths, dust and heat. Every node rides through power blips; every zone has its own link. |
| R7 See everything from one tent | A small team runs the network from the NOC. They need to know which zone is unhappy before someone radios it in. |
| R8 Leave nothing behind | Vendor Wi-Fi keys and payment details must not survive on gear that goes to the next event. |
02
Each one would be wrong in a permanent building and is right in a field.
Each zone (gates, food court, stage) has one link back to the NOC tent: 60 GHz radios where there's line of sight over the trees, an armoured fibre to the food court because it's close and carries the most users. A star, not a chain, means a failed link takes out one zone, and the NOC sees exactly which one. 60 GHz is chosen because it's fast, ignores the 5 GHz Wi-Fi congestion, and works fine at festival distances in dry summer weather. Every link is surveyed on Monday and re-aimed if a stage truck ends up in the path.
Covering 3,000 people across an open field with Wi-Fi would mean dozens of APs fighting for airtime. Instead, the public SSID exists only where people sit still (the food court and charging area), and phones elsewhere use mobile data. That keeps the public network to a handful of APs that can be properly planned for density.
Two Starlinks and one 5G line, each with a role. Starlink A carries the critical zones and the (shaped) public. Starlink B belongs to the live stream alone. 5G is the backup for the critical zones only. Routing tables, not firewall rules, decide which line each zone may use, so "the public never touches 5G" is simply true: their table has no route there.
Ten nodes configured by hand in a tent is ten chances for a typo at 07:00 on opening day. Every node's config is generated from one template in the workshop, tested on the bench as a complete network, labelled, and packed. On site, nobody types a config.
03
Small subnets for things you count, one big subnet for the crowd. The public /21 breaks the "third octet = VLAN" rule on purpose.
| VLAN · subnet | Who lives here · notes |
|---|---|
| 10 STAFF · 10.80.10.0/24 | Organiser, security, first aid tablets. Critical line. |
| 20 TICKETING · 10.80.20.0/24 | 12 scanners (reservations), gate supervisors' laptops. Critical line. |
| 25 PAYMENTS · 10.80.25.0/24 | Vendor terminals and tills (wired where possible, SSID EVT-PAY otherwise). Critical line. |
| 30 PRODUCTION · 10.80.30.0/24 | Stream encoder .10, stage LAN. Starlink B only. |
| 40 PRESS · 10.80.40.0/24 | Press-tent desks and press Wi-Fi. |
| 50 PUBLIC · 10.80.48.0/21 | Food court and charging area. 2,000+ addresses, 15-minute leases, client isolation. |
| 99 MGMT · 10.80.99.0/24 | R1 .1, NOC-SW .2, zone switches .11–.13, radios .21–.26, APs .31+. |
| WAN | ether1 Starlink A, ether2 Starlink B (both bypass mode, CGNAT), ether3 5G (passthrough). |
04
Rows start, columns receive. Default deny. Who may talk to whom is the firewall; which line they use is routing.
The Production → Press cell is the one exception to "zones don't talk": journalists receive a program feed from the encoder, pushed by the encoder to a receiver in the press tent. The press can't connect to the encoder itself, so nobody in the tent can change the live stream's settings.
04b
Every requirement from the brief, the steps that implement it, the config that does it, and the test that proves it.
| Requirement | Implemented in | Key config | Proven by |
|---|---|---|---|
| R1 Gates never stop | step 2 · step 5 | own 60 GHz link to the gates; scanners with an offline ticket list | "Gate link cut" drill, section 15 |
| R2 Bars never stop | step 6 · step 7 | payments VLAN HTTPS-out only; crit table falls back to 5G | "Starlink A stowed" drill |
| R3 The stream never stutters | step 7 | prod table: Starlink B first, A second | "Stream under load" drill |
| R4 Public Wi-Fi where it matters | step 4 · step 5 · step 8 | /21 with 15-min leases; public SSID in the food court only; 2 Mb/s per phone, 60/8 total | "Crowd simulation" drill |
| R5 Build in a day | step 1 | generated per-node configs, tested on the bench | Every .rsc imports cleanly on a reset device |
| R6 Survive the field | step 2 | star backhaul; battery per node | "Generator switchover" drill |
| R7 See everything from one tent | step 9 | netwatch per zone and per line, warnings to the NOC laptop | "NOC view" drill |
| R8 Leave nothing behind | step 10 | final export + log kept; reset to staging config | Teardown checkpoint |
The build
Steps 1–5 happen twice: first on a workbench in the workshop, then in the field. Every checkpoint is run in both places.
Ten steps: the NOC, the backhaul links, the zone devices, addressing, Wi-Fi, the firewall, the three internet lines, public limits, monitoring, and teardown. The order is the same bottom-up order as the other Build posts, but with a twist: the whole network is first assembled on one table, with a spare Starlink and a 5G router as the WAN, and run for a day with test devices before anything goes into a case.
05 · Step 1 of 10
One router and one SFP switch in the NOC tent. Every node in the field gets its config from the same template.
▲ Show step 1 in the interactive topology · see what this step adds, and click any device for its config
{# the same idea on Cisco: a Jinja2 template rendered per node (Ansible or a short script) #}
hostname {{ name }}
{% for v in vlans %}vlan {{ v }}
{% endfor %}vlan 99
interface {{ trunk }}
description backhaul
switchport mode trunk
switchport trunk allowed vlan {{ vlans | join(',') }},99
interface Vlan99
ip address {{ mgmt_ip }} 255.255.255.0
ip default-gateway 10.80.99.1
ntp server 10.80.99.1
logging host 10.80.99.5{
:local name "GATE-SW"
:local mgmt "10.80.99.11/24"
:local trunkPort "ether16"
:local vlans "10,20"
/system identity set name=$name
/interface bridge add name=bridge vlan-filtering=no
/interface bridge port add bridge=bridge interface=$trunkPort frame-types=admit-only-vlan-tagged comment="backhaul"
/interface bridge vlan add bridge=bridge vlan-ids=$vlans tagged=($trunkPort . ",ether1,ether2")
/interface bridge vlan add bridge=bridge vlan-ids=99 tagged=("bridge," . $trunkPort)
/interface vlan add name=v99-mgmt interface=bridge vlan-id=99
/ip address add address=$mgmt interface=v99-mgmt
/ip route add gateway=10.80.99.1
/system ntp client set enabled=yes servers=10.80.99.1
/system logging action add name=noc target=remote remote=10.80.99.5
/system logging add topics=warning action=noc
/interface bridge set bridge vlan-filtering=yes
}A ten-line generator (any scripting language) fills in the first block from a node table: name, management address, trunk port, VLANs. It writes one .rsc per node, and each node is reset and imports its file on the bench. The braces matter: RouterOS runs an imported file line by line, and :local variables only survive across lines inside a block.
/system identity set name=R1
/interface bridge add name=bridge vlan-filtering=no
/interface bridge port add bridge=bridge interface=sfp-sfpplus1 frame-types=admit-only-vlan-tagged
/interface bridge vlan add bridge=bridge vlan-ids=10,20,25,30,40,50,99 tagged=bridge,sfp-sfpplus1
/interface vlan
add name=v10-staff interface=bridge vlan-id=10
add name=v20-ticket interface=bridge vlan-id=20
add name=v25-pay interface=bridge vlan-id=25
add name=v30-prod interface=bridge vlan-id=30
add name=v40-press interface=bridge vlan-id=40
add name=v50-public interface=bridge vlan-id=50
add name=v99-mgmt interface=bridge vlan-id=99
/ip address add address=10.80.99.1/24 interface=v99-mgmt
# … .1 on each /24; the public /21 in step 4
/system ntp server set enabled=yes
/interface bridge set bridge vlan-filtering=yes.rsc imports on a reset device without errors (/import file=gate-sw.rsc verbose=yes).06 · Step 2 of 10
Three zones, three links back to the NOC. A link failure costs one zone, never the site.
▲ Show step 2 in the interactive topology · see what this step adds, and click any device for its config
| Link | Hardware · notes |
|---|---|
| NOC → gates (180 m) | wAP 60G pair on 3 m masts, aimed over the olive canopy. Transparent bridge for the trunk (as in the villa). Survey on Monday, re-check after the stage trucks arrive. |
| NOC → food court (90 m) | Armoured outdoor fibre, buried 10 cm or run along a fence, SFP+ at both ends. The busiest zone gets the link that can't be blocked by a truck. |
| NOC → stage (240 m) | wAP 60G pair. A spare pair and two 5 GHz point-to-point radios are in the NOC case as a quick replacement if a 60 GHz path gets blocked for good. |
| Zone switches | netPower 16P: outdoor, 16 PoE-out gigabit ports and SFP+, mounted in a ventilated box at the foot of each mast. Each powers its APs and the radio. |
A 60 GHz beam is narrow, and anything solid in it (a truck, a tent roof, a crowd standing on a ridge) blocks it. Mount the radios high, aim over the trees and people rather than through them, and plan the mast positions with the production manager, who knows where the trucks will park. Rain at these distances is a non-issue; dust on the radomes is wiped off every morning.
/interface w60g monitor wlan60-1 on each radio: connected, rate in the Gb/s range, signal stable over ten minutes.07 · Step 3 of 10
Gate APs for the scanners, food-court APs for tills and the public, stage APs for staff and press, plus the wired devices in each zone.
▲ Show step 3 in the interactive topology · see what this step adds, and click any device for its config
| Zone switch | Ports |
|---|---|
| GATE-SW | ether1–2: gate APs (trunk: mgmt untagged, 10 + 20 tagged) · ether16: radio |
| FOOD-SW | ether1–10: vendor tills that have Ethernet (VLAN 25) · ether11–14: public/pay APs (trunk: 10, 25, 50) · sfp-sfpplus1: fibre |
| STAGE-SW | ether1: stream encoder (VLAN 30) · ether2–5: press desks (VLAN 40) · ether6–7: stage APs (trunk: 10, 40) · ether16: radio |
Six public APs serve the food court and charging area. That's planned for ~1,200 concurrent phones (about 200 per AP), which is the practical ceiling for a Wi-Fi 6 AP with small channels and low per-device rates. More APs in the same area wouldn't add capacity; they'd add interference. The APs are mounted 3–4 m up on the food-court poles, pointing down at the crowd, at reduced transmit power, so each covers a small area.
08 · Step 4 of 10
The public VLAN gets a /21 and 15-minute leases. Everything else is small and boring.
/ip address add address=10.80.48.1/21 interface=v50-public /ip pool add name=p-public ranges=10.80.48.10-10.80.55.250 /ip dhcp-server add name=d-public interface=v50-public address-pool=p-public lease-time=15m /ip dhcp-server network add address=10.80.48.0/21 gateway=10.80.48.1 dns-server=10.80.48.1 # critical zones: small pools, reservations for every scanner and known till /ip dhcp-server add name=d-ticket interface=v20-ticket address-pool=p-ticket lease-time=12h /ip dhcp-server lease add server=d-ticket mac-address=00:24:2B:00:00:01 address=10.80.20.41 comment="scanner G-A-01" # … the other zones the same way /ip dns set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220 cache-size=8192KiB \ max-concurrent-queries=500
The arithmetic: about 3,000 people a day, perhaps a third of them on the public Wi-Fi at some point, and phones that come and go every few minutes. With 2-hour leases, a busy afternoon would leave hundreds of addresses held by phones that left long ago. Fifteen-minute leases recycle them. A /21 (about 2,000 addresses) gives headroom on top. DNS gets a bigger cache and more concurrent queries, because thousands of phones all looking up the same few apps is exactly what a cache is for. The resolvers aren't 1.1.1.1 or 9.9.9.9, because those become the probe addresses in step 7.
/ip dhcp-server lease print count-only where server=d-public matches.09 · Step 5 of 10
CAPsMAN gives each zone's APs only the SSIDs that zone needs. The scanners' offline mode covers what the network can't.
/interface wifi datapath add name=dp-scan bridge=bridge vlan-id=20 add name=dp-pay bridge=bridge vlan-id=25 add name=dp-staff bridge=bridge vlan-id=10 add name=dp-press bridge=bridge vlan-id=40 add name=dp-public bridge=bridge vlan-id=50 client-isolation=yes /interface wifi configuration add name=cfg-scan ssid=EVT-SCAN security=sec-scan datapath=dp-scan country=Greece hide-ssid=yes add name=cfg-pay ssid=EVT-PAY security=sec-pay datapath=dp-pay country=Greece hide-ssid=yes add name=cfg-staff ssid=EVT-STAFF security=sec-staff datapath=dp-staff country=Greece hide-ssid=yes add name=cfg-press ssid=FESTIVAL-Press security=sec-press datapath=dp-press country=Greece add name=cfg-public ssid=FESTIVAL-Free datapath=dp-public country=Greece channel.width=20mhz /interface wifi provisioning add action=create-dynamic-enabled identity-regexp="^GATE-AP" master-configuration=cfg-scan slave-configurations=cfg-staff add action=create-dynamic-enabled identity-regexp="^FOOD-AP" master-configuration=cfg-public slave-configurations=cfg-pay,cfg-staff add action=create-dynamic-enabled identity-regexp="^STAGE-AP" master-configuration=cfg-press slave-configurations=cfg-staff
Public Wi-Fi uses 20 MHz channels: in a dense crowd, more non-overlapping channels beat wider ones. The scanners' SSID only exists at the gates, so a scanner carried off to the bar doesn't wander onto a weak signal and slow down the line. Vendors who brought Wi-Fi-only tills join EVT-PAY with a key handed out at check-in. Wired tills are preferred and get the FOOD-SW ports.
No backhaul is perfect for four days. The scanners handle that themselves: they download the ticket list before the gates open, validate online when they can, and fall back to the local list when they can't.
10 · Step 6 of 10
Every zone reaches its own cloud. The only zone-to-zone flow is the press feed, and it goes one way.
/ip firewall address-list
add list=TICKET-API address=api.tickets.example comment="from the ticketing company"
add list=PRESS-RX address=10.80.40.50 comment="feed receiver in the press tent"
/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked
add chain=input action=drop connection-state=invalid
add chain=input action=accept protocol=icmp
add chain=input action=accept in-interface=v99-mgmt
add chain=input action=accept in-interface-list=LAN protocol=udp dst-port=53,67,123
add chain=input action=accept in-interface-list=LAN protocol=tcp dst-port=53
add chain=input action=drop
add chain=forward action=accept connection-state=established,related,untracked
add chain=forward action=drop connection-state=invalid
add chain=forward action=accept in-interface=v20-ticket dst-address-list=TICKET-API protocol=tcp dst-port=443
add chain=forward action=accept in-interface=v25-pay out-interface-list=WAN protocol=tcp dst-port=443 \
comment="vendors bring their own terminals and acquirers: HTTPS out, nothing else"
add chain=forward action=accept in-interface=v30-prod dst-address-list=PRESS-RX protocol=udp dst-port=9000 \
comment="program feed to the press tent (SRT)"
add chain=forward action=accept in-interface=v30-prod out-interface-list=WAN
add chain=forward action=accept in-interface=v10-staff out-interface-list=WAN
add chain=forward action=accept in-interface=v40-press out-interface-list=WAN
add chain=forward action=accept in-interface=v50-public out-interface-list=WAN
add chain=forward action=accept in-interface=v99-mgmt
add chain=forward action=drop log=yes log-prefix=FWD-DROPIn the coffee shop, the payment VLAN could only reach one acquirer's host names. At a festival, every vendor arrives with their own terminal from their own bank, and nobody has the full list of host names until Thursday morning. So the payment VLAN gets HTTPS out to anything, and DNS from R1, but nothing inbound and nothing inside the site. That still keeps every till away from three thousand phones, which is the risk that actually matters here.
11 · Step 7 of 10
Routing tables decide which line each zone may use. Failover happens inside each table.
▲ Show step 7 in the interactive topology · see what this step adds, and click any device for its config
/interface list member
add list=WAN interface=ether1
add list=WAN interface=ether2
add list=WAN interface=ether3
/ip route
add dst-address=1.1.1.1/32 gateway=100.64.0.1 scope=10 comment="probe A"
add dst-address=9.9.9.9/32 gateway=100.64.0.1 scope=10 comment="probe B"
/ip dhcp-client
add interface=ether1 add-default-route=no use-peer-dns=no comment="Starlink A" \
script={ :if ($bound=1) do={ /ip route set [find comment="probe A"] gateway=$"gateway-address" } }
add interface=ether2 add-default-route=no use-peer-dns=no comment="Starlink B" \
script={ :if ($bound=1) do={ /ip route set [find comment="probe B"] gateway=$"gateway-address" } }
add interface=ether3 add-default-route=no use-peer-dns=no comment="5G" \
script={ :if ($bound=1) do={ /ip route set [find comment="crit via 5G"] gateway=$"gateway-address" } }
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN! R1 — C8300: policy routing with tracked next hops instead of routing tables. ! IOS PBR needs fixed next hops, so each Starlink keeps its own router (not bypass mode) ! and hands R1 a stable LAN address: A = 192.168.1.1, B = 192.168.2.1, 5G = 192.168.8.1. route-map PBR-ZONES permit 10 match ip address CRIT-SRC ! staff, scanners, tills set ip next-hop verify-availability 192.168.1.1 1 track 1 set ip next-hop verify-availability 192.168.8.1 2 track 3 route-map PBR-ZONES permit 20 match ip address PROD-SRC ! the stream set ip next-hop verify-availability 192.168.2.1 1 track 2 set ip next-hop verify-availability 192.168.1.1 2 track 1 route-map PBR-ZONES permit 30 match ip address PUBLIC-SRC ! public and press set ip next-hop verify-availability 192.168.1.1 1 track 1 set interface Null0 ! A down: no other line for them interface GigabitEthernet0/0/2.900 ip policy route-map PBR-ZONES
/routing table add name=crit fib add name=prod fib /ip route # main (public, press): Starlink A only add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 # crit (staff, scanners, tills): Starlink A, then 5G add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=1 routing-table=crit add dst-address=0.0.0.0/0 gateway=100.64.0.1 distance=2 routing-table=crit comment="crit via 5G" # prod (live stream): Starlink B, then Starlink A add dst-address=0.0.0.0/0 gateway=9.9.9.9 target-scope=11 check-gateway=ping distance=1 routing-table=prod add dst-address=0.0.0.0/0 gateway=1.1.1.1 target-scope=11 check-gateway=ping distance=2 routing-table=prod /routing rule add dst-address=10.80.0.0/16 action=lookup-only-in-table table=main comment="site stays on site" add src-address=10.80.10.0/24 action=lookup table=crit add src-address=10.80.20.0/24 action=lookup table=crit add src-address=10.80.25.0/24 action=lookup table=crit add src-address=10.80.30.0/24 action=lookup table=prod
Read it by zone. The public and press use the main table: Starlink A, and nothing else. If A fails they lose internet until it returns. That's the deliberate price of keeping B for the stream and 5G for the gates and tills: no route in that table points at either. The critical zones fall back from Starlink A to 5G and never compete with the stream. The stream has Starlink B to itself and borrows Starlink A only if B dies. The first rule is the lesson from the gaming center: without it, traffic between zones would be looked up in tables that only know default routes, and leave the site.
/routing rule print and /ip route print where routing-table=crit: as above, with the probe gateways filled in by the DHCP scripts.12 · Step 8 of 10
2 Mb/s per phone and 60 Mb/s for the whole public network. The critical zones are never shaped.
! R1 — the total cap is a policer on the public subinterface; ! the 2 Mb/s per phone moves to the wireless controller (per-client rate limit) policy-map PUBLIC-CAP class class-default police cir 60000000 interface GigabitEthernet0/0/2.50 service-policy output PUBLIC-CAP
/queue type add name=pcq-pub-down kind=pcq pcq-classifier=dst-address pcq-rate=2M add name=pcq-pub-up kind=pcq pcq-classifier=src-address pcq-rate=1M /queue simple add name=public target=10.80.48.0/21 max-limit=8M/60M queue=pcq-pub-up/pcq-pub-down
2 Mb/s is enough for messaging, maps and social media, which is what a festival crowd wants; it's not enough to stream video, which is the point. The 60/8 Mb/s cap leaves most of Starlink A for the critical zones, which are tiny in volume but need their packets to go through immediately. With the critical zones unshaped and the public capped well below the line rate, the queue never forms where it would hurt a payment.
/queue simple print stats where name=public shows the cap working, and a test card payment completes in its usual time.13 · Step 9 of 10
Know which zone is unhappy before the radio call comes in.
! R1 — IP SLA per zone switch, EEM turns state changes into syslog warnings ip sla 11 icmp-echo 10.80.99.11 frequency 10 ip sla schedule 11 life forever start-time now track 11 ip sla 11 reachability event manager applet ZONE-GATES event track 11 state any action 1.0 syslog priority warnings msg "ZONE GATES changed state" ! … the same for FOOD-SW (.12), STAGE-SW (.13) and each internet line logging host 10.80.99.5
/tool netwatch
add host=10.80.99.11 interval=10s comment="GATE-SW" \
down-script=":log warning \"ZONE GATES DOWN\"" up-script=":log warning \"ZONE GATES UP\""
add host=10.80.99.12 interval=10s comment="FOOD-SW" \
down-script=":log warning \"ZONE FOOD DOWN\"" up-script=":log warning \"ZONE FOOD UP\""
add host=10.80.99.13 interval=10s comment="STAGE-SW" \
down-script=":log warning \"ZONE STAGE DOWN\"" up-script=":log warning \"ZONE STAGE UP\""
add host=1.1.1.1 interval=15s down-script=":log warning \"STARLINK A DOWN\"" up-script=":log warning \"STARLINK A UP\""
add host=9.9.9.9 interval=15s down-script=":log warning \"STARLINK B DOWN\"" up-script=":log warning \"STARLINK B UP\""
/system logging action add name=noc target=remote remote=10.80.99.5
/system logging add topics=warning action=nocThe NOC laptop runs a syslog view and a network map (The Dude, MikroTik's free monitoring tool, or any SNMP dashboard) on a big screen. Three numbers tell you most of what's happening: the status of the five watches, the count of public DHCP leases (a proxy for how full the food court is), and the 60 GHz links' signal levels. When the gate link goes down, the NOC knows before the gate supervisor reaches for the radio, and the scanners are already working offline.
14 · Step 10 of 10
Sunday night the field goes back to being a field, and the gear goes back into cases without this festival's secrets on it.
! every node — keep the evidence, then return to the staging config show logging | redirect flash:festival-log.txt copy running-config flash:festival-final.cfg ! copy both files to the NOC laptop, then: configure replace flash:staging.cfg force write memory
# on R1, before anything is unplugged /log print file=festival-r1-log /export file=festival-r1-final # copy both files off to the NOC laptop, then on every node: /system reset-configuration no-defaults=yes skip-backup=yes run-after-reset=flash/staging.rsc
The final export and the log are the raw material for the post-event review: which link dropped and when, peak public leases, how long Starlink A was out, how many offline scans were uploaded. They're stored with the organiser's documentation. Then every node is reset to its staging config, a minimal file with only a management address, so the Wi-Fi keys, vendor credentials and the organiser's network design don't travel to the next event. Labelled cables go back into labelled bags, and the case inventory is checked against Monday's list before the truck leaves.
/interface wifi security print on R1 is empty.15
Wednesday afternoon, with the crew as the crowd: break everything once before 3,000 people arrive.
| Drill (requirement) | What must happen |
|---|---|
| Gate link cut (R1) | Unplug the gate radio during a scan run: scanning continues offline; after reconnection all scans sync. |
| Starlink A stowed (R2) | Tills and scanners continue via 5G in ~20 s; the public and press drop (expected); the stream continues. |
| Stream under load (R3) | Saturate Starlink A from test phones: the stream's bitrate on B doesn't move. |
| Crowd simulation (R4) | A DHCP load tester plus every crew phone on FESTIVAL-Free: leases issued, per-phone cap at ~2 Mb/s, a card payment unaffected. |
| Generator switchover (R6) | Switch the generators over: every node rides through on its battery; no zone drops. |
| NOC view (R7) | Each simulated failure shows on the NOC screen before anyone radios it in. |
| Isolation (all) | From the public SSID, nothing on site answers; from the press tent, the encoder's UI doesn't load. |
16
What a temporary network can't fully control, and what covers each gap.
17
The routing tables, failover, queues, netwatch and the generated configs all run on CHR.
| This post | In the lab |
|---|---|
| R1 and three WANs | A CHR with three upstream "ISP" CHRs that hand out 100.64.x addresses by DHCP. Change a gateway or block 1.1.1.1 on one to test the scripts and tables. |
| Zones and backhaul | CHR bridges for NOC-SW and the zone switches; virtual links instead of radios. Disconnect a link to test netwatch. |
| Generated configs | Import each node's .rsc into a fresh CHR: the best test that the template has no typos. |
| Crowd | A DHCP load tester (dhcperf, or many small containers) on VLAN 50. |
18
Indicative EU street prices, late 2026, excluding VAT. This kit is reused at every event; Starlink service plans are monthly.
| Item | Indicative (EUR, ex VAT) |
|---|---|
| R1 · CCR2004-16G-2S+ | 450 – 550 |
| NOC-SW · CRS326-24S+2Q+ + SFP modules | 550 – 750 |
| 3× netPower 16P (zone switches) | 900 – 1,200 |
| 2× wAP 60G pairs + 1 spare pair | 540 – 780 |
| 100 m armoured fibre + SFP+ optics | 200 – 350 |
| ~12× outdoor wAP ax | 1,600 – 2,000 |
| 2× Starlink kits + 5G router | Starlink hardware per current offer, plus 300 – 450 for the 5G router; service plans monthly |
| Battery/UPS per node (×5), masts, tripods, enclosures, cases | 1,800 – 3,000 |
| Reusable kit total (excl. Starlink) | ≈ 6,300 – 9,100 |
Appendix
Same festival, same zones and lines, on Cisco gear (more often rented than bought for an event). The Cisco tabs on the config blocks above show the key differences.
| Role | This post → Cisco |
|---|---|
| R1 | CCR2004-16G-2S+ → C8300-1N1S-6T |
| NOC-SW | CRS326-24S+2Q+ → Catalyst 9300 with an SFP+ module |
| Zone switches (outdoor) | netPower 16P → rugged Catalyst IE switches in ventilated enclosures |
| 60 GHz links | wAP 60G pairs → third-party 60 GHz bridges or Cisco industrial wireless backhaul |
| Wi-Fi | outdoor wAP ax + CAPsMAN → outdoor Catalyst APs with a controller |
| Reusable kit (excl. Starlink) | ≈ 6,300 – 9,100 → ≈ 30,000 – 45,000 EUR ex VAT, usually rented |
| Feature | This post → Cisco |
|---|---|
| Generated configs | .rsc with a variables block → Jinja2 templates |
| Lines per zone | routing tables + rules → PBR with tracked next hops |
| Starlink | bypass mode, DHCP gateways → Starlink routers kept, fixed next hops for PBR |
| Public limits | PCQ simple queue → total policer on the router + per-client limit on the controller |
| Zone and line watches | netwatch → IP SLA + EEM syslog |
| Teardown | reset-configuration run-after-reset → configure replace to the staging config |
Policy routing wants fixed next hops. MikroTik routing tables work happily with gateways learned by DHCP and updated by a script; IOS PBR needs addresses it can track. So on Cisco each Starlink keeps its own router, adding a double-NAT that nothing on this network minds. Per-phone limits move to the Wi-Fi controller, which is the more natural place anyway. Everything else translates directly.
Takeaways
This is part 7 of the Build series. Earlier: the law firm, the gaming center, the coffee shop, the supermarket, the medical clinic, the holiday villa. Next: the esports arena.
Festivals, conferences, weddings and sports events: I plan and run temporary networks like this one, with Starlink, radio links and Wi-Fi where your guests are, and the payments and gates protected first.
Book a Discovery Call →