The rest of this series is how each piece works. This is what happens when you put them together for money, on a deadline, in a building with 30cm stone walls and one fibre drop that goes down every time it rains. An anonymised write-up of a real collapsed-core Cisco build for a seaside hotel — the design, the dual-WAN failover onto Starlink, and the three things that broke in the first week.
Client details, addresses, SSIDs and public IPs are changed or generalised; topology and numbers are representative of the real build, not a copy of the live config. Shared with permission. The point is the decisions, not the client.
01
A 40-room seaside hotel, family-run, that had grown its network by accretion: one flat /24, a consumer router, and a Wi-Fi password shared with every guest since 2019. They wanted "faster Wi-Fi." What they needed was a network.
The real requirements, once we talked through them: guests must never reach the property-management system (the PMS holds card and passport data), the CCTV must be isolated and recorded reliably, the VoIP phones at reception can't crackle when the lobby fills with guests streaming, and the whole thing must stay online when the single fibre drop dies — which, in this village, it does. Budget was real but not infinite: one managed Layer-3 switch acting as collapsed core, existing cabling, and Starlink as the second WAN because there's no second wired provider for 20km.
Standard Starlink hands you a CGNAT address, not a public one. That's fine for a backup path where the hotel only makes outbound connections, but it means Starlink can't terminate an inbound VPN or host anything. It forced the design decision early: fibre is primary and carries anything inbound; Starlink is outbound-only survival. Knowing this on day one saved a doomed afternoon trying to port-forward the CCTV over the backup link. (Details in Starlink + MikroTik Failover — same CGNAT reality, different edge.)
02
A 40-room hotel does not need a three-tier campus. It needs one intelligent box that both switches and routes, with clean segmentation on top. Collapsed-core is the honest answer at this scale.
One Layer-3 switch is the core and the distribution layer; access switches hang off it for the room floors. Inter-VLAN routing happens on the core with SVIs, and the same box handles the two WAN uplinks. Simpler to run, cheaper, and for a single building with no redundancy requirement between floors, entirely appropriate — the pattern from the collapsed-core lab put into a real cabinet.
| VLAN | Purpose & policy |
|---|---|
| 10 · Staff | Back-office PCs; reaches internet + PMS (print/booking), nothing else. |
| 20 · Guest | Room + lobby Wi-Fi. Internet only. /23 for DHCP headroom. Client isolation on. |
| 30 · PMS | Booking/POS terminals + server. No inbound from guest/CCTV; card-data zone. |
| 40 · CCTV | Cameras + NVR. No internet at all — recorded on-prem, reachable only by staff. |
| 50 · VoIP | Reception phones. Priority-queued; own subnet for clean QoS marking. |
| 99 · Mgmt | Switch/AP management. Locked to a single admin host + SSH only. |
The segmentation isn't paranoia — it's the difference between "a guest laptop got malware" and "a guest laptop got malware and it reached the machine with everyone's passport scans." The inter-VLAN policy is enforced with ACLs on the SVIs, exactly the pattern from the ACL post: default-deny between segments, explicit allows for the few flows that must cross (staff→PMS, staff→CCTV).
# Applied inbound on the Guest SVI: internet yes, internal no. Core(config)# ip access-list extended GUEST-IN Core(config-ext-nacl)# deny ip 10.10.20.0 0.0.1.255 10.10.0.0 0.0.255.255 # no internal RFC1918 Core(config-ext-nacl)# permit ip 10.10.20.0 0.0.1.255 any # everything else (internet) Core(config)# interface Vlan20 Core(config-if)# ip access-group GUEST-IN in
The ACL stops a guest routing to the PMS. It does not stop guest-to-guest traffic inside VLAN 20 — that's the same broadcast domain, so one infected laptop can still scan and attack the phone in the next room. The second layer is protected-port / client isolation at the access layer (and on the APs) so guest devices can talk to the gateway and nothing else on their own VLAN. Owners think the Wi-Fi password is the security boundary; it isn't. This pairs with the plain-language Why Guest Wi-Fi Needs Its Own Network I hand to non-technical clients.
03
The whole reason the owner called. When the fibre drops mid-season, reception still needs to take bookings and the card terminal still needs to clear. Failover has to be automatic and quiet — no one at the desk should have to do anything.
Two default routes with different administrative distances, and an IP SLA probe tracking real reachability out the fibre — not just "is the interface up," because the fibre link stays up while the provider's upstream is dead. When the probe fails, the tracked primary route withdraws and the higher-AD Starlink route takes over. When the probe recovers, it fails back.
# Probe a reliable off-net target THROUGH the fibre next-hop. Edge(config)# ip sla 1 Edge(config-ip-sla)# icmp-echo 1.1.1.1 source-interface GigabitEthernet0/0 Edge(config-ip-sla)# frequency 5 Edge(config)# ip sla schedule 1 life forever start-time now Edge(config)# track 1 ip sla 1 reachability # Primary via fibre, only while track 1 is up (AD 1). Edge(config)# ip route 0.0.0.0 0.0.0.0 <fibre-gw> 1 track 1 # Backup via Starlink, worse AD so it only installs when primary is gone. Edge(config)# ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/1 10 # Starlink (DHCP/CGNAT)
First failover test: fibre pulled, route flipped to Starlink correctly, and nothing reached the internet. The PAT overload was configured to translate only out the fibre interface. When traffic started leaving via Starlink it was unNATed — a CGNAT-inside-a-private-address that Starlink silently dropped. The fix: a second ip nat inside source rule (route-map matched to each egress interface) so translations follow whichever WAN is live. It's the classic dual-WAN NAT gotcha, and it only shows up the moment the backup path is actually used — which is why you test failover before you leave site, not when the owner calls in August.
04
Every honest field write-up has this section. The design was right; reality still had opinions. Two more from the first week.
Phones were on their own VLAN but QoS hadn't been carried onto the WAN uplink. Under load, the fibre's tiny upload buffer bloated and voice packets queued behind guest uploads. The QoS post is exactly this: mark voice EF at the access edge, then a priority queue with a policing ceiling on the WAN egress so guest traffic can never starve the phones. Silence fixed in one policy-map. Lesson: QoS marking without an egress policy on the bottleneck link is decoration.
The NVR dropped a camera or two every few hours. Not the network — PoE budget. The access switch's total PoE draw was over its budget with all cameras plus the two lobby APs, so it was shedding the lowest-priority ports under peak. Re-homed the APs to a second switch and set PoE priority on the camera ports. A reminder that "the network is dropping things" is sometimes a power-budget spreadsheet, and that syslog (the switch was logging ILPOWER events the whole time) tells you which.
Before leaving: config archived and backed up off-box, syslog + NTP pointed at a small collector so timestamps mean something, SSH-only management on VLAN 99, and a one-page runbook taped inside the cabinet — "fibre's down? here's how you know it failed over, here's who to call." The owner can't read a running-config, but they can read that page. Documentation is the deliverable that outlives the visit.
Takeaways
NOCTIS designs segmented, dual-WAN Cisco and MikroTik networks that keep guests off your card data and stay online when the fibre doesn't — with Starlink backup, clean QoS, and documentation your staff can actually use.
Book a Discovery Call →