Cloud-Managed Networking with Cisco Meraki

You do not have to buy all five lines, and most organisations do not. The usual entry point is the branch security appliance plus access points, with switching adopted later as existing hardware reaches end of life. Mixed estates work perfectly well — a third-party switch behind a Meraki security appliance is not a problem. You simply cannot manage that switch's ports from the dashboard, and that part of the estate stays conventional, with its own configuration file and its own change process.

The defining property of the dashboard is not that it is a screen. It is that the system of record for configuration has moved. On a conventional deployment the configuration lives in the device's memory; if the device dies, the configuration dies with it and, absent a backup, everything gets rewritten from scratch by whoever is available at the time. Under cloud management the device carries a copy of the configuration but does not own it. The everyday consequence of that distinction is the subject of the next section, and it is the part clients feel first.

The real value of this flow shows up during a failure rather than at opening. When a security appliance dies at a branch two hours outside Antalya, the conventional sequence is predictable: buy a replacement, configure it centrally, courier it or drive it out, install it on site, and then spend several hours on the phone because something does not match. The branch is measured as down in days, not hours, and the cost is rarely just the hardware.

With cloud management the same event runs differently. The replacement serial is registered in place of the old one, the box is couriered, somebody at the branch plugs it in, and it pulls the previous configuration for itself. Downtime shrinks from an engineer's travel time to a courier's transit time. For sites where even that is too long, we hold a shelf spare, and the transit disappears as well. It is worth calculating this properly during the business case: for an estate spread across Alanya, Antalya and Istanbul, the avoided travel is frequently the largest single number on the page.

The craft in template design lies in deciding correctly what is common and what is local. A template that is too rigid frustrates sites, and people start requesting exceptions until the exception list is longer than the template. A template that is too loose degenerates into forty separate configurations within a year, and the entire benefit of centralised management evaporates while you are still paying for it. The balance we normally strike is this: security rules, authentication and traffic policy live firmly in the template; addressing, circuit details and local device counts live in per-site variables.

Tags are the second layer of that structure. In a retail chain, a high-street shop and a shopping-centre unit do not run the same policy — trading hours differ, guest network expectations differ, and the circuit type differs. Splitting them into two separate templates duplicates everything they have in common; tagging keeps the shared rules in one place while still letting the difference be expressed. The same method serves temporary locations well. A construction site office is tagged, given its policy, and when the project ends the tag is removed, the site is retired from the dashboard, and the hardware goes to the next project without anyone rebuilding it.

It is worth stating the risk plainly alongside the benefit. Because a template reaches every bound site at once, an error in it also reaches every site at once. We therefore treat template edits with more ceremony than device-level edits: change is described in writing, applied to a pilot site, observed, and only then rolled out. Centralisation does not remove the need for a change process — it makes one mandatory.

There is only one question behind the topology decision: in this network, where does the data go? In hotel groups the answer is normally the centre — the reservation system, accounting and reporting sit in one place, and hub-and-spoke is sufficient. In estates with heavy branch-to-branch voice or direct file access between sites, traffic that travels to the hub and back adds both latency and needless load on the hub circuit, and direct tunnels earn their keep. The decision comes from measurement rather than habit, and it is worth revisiting once a year as the business changes.

Tunnel design is also an access decision, not merely a connectivity one. A branch does not need to reach everything at head office; usually a handful of servers and services is enough. Restricting which subnets enter the tunnel reduces traffic and, more importantly, limits how far an incident at one site can spread. We cover that reasoning in more depth on the VPN setup page, and the segmentation side on network security.

How failover feels to a user is the least discussed and most important part of this subject. If a circuit fails during a voice call, two things can happen. With the policy written correctly, the call carries on through a brief distortion; the user usually does not realise the path changed and reports only that "it cut out for a second". Without it, the call drops, the phone system attempts to re-register, and the customer who was calling has already hung up. The difference between those two outcomes is configuration, not hardware, and it is invisible on a purchase order.

In Turkish conditions, provisioning the second circuit as a mobile connection is both common and sensible. When fibre is cut — something we see regularly during summer excavation work along the coast — the mobile path takes over, the tills keep working and payments keep clearing. That scenario makes one policy mandatory: backup and update traffic must be prevented from using the mobile path at all, so that only business traffic crosses it. Without that rule, a single day of failover consumes the month's data allowance, and the second outage that month has no second circuit behind it.

Dual-circuit design also changes what you should expect from monitoring. A site running happily on its backup path looks entirely healthy on a status page while quietly sitting on a circuit with a fraction of the capacity. Alerting on the failover event itself, rather than on the eventual symptom, is the difference between noticing in minutes and noticing when the invoice arrives.

The mistake we meet most often in hotels is treating a wireless complaint as a coverage complaint. When a guest says the internet is not working, there is usually plenty of signal; what is congested is the channel. Access points on the same channel across several floors take turns rather than transmitting, and as occupancy climbs that waiting surfaces to the guest as slowness. The fix is frequently not another access point but lower transmit power and a corrected channel plan — counter-intuitive, and repeatedly effective in the field.

Authentication is where hotels and clinics part company. A hotel guest network opens through a captive portal and often expects verification against a room number, which is a structure of its own and is covered on the hotspot and guest network page. In clinics and offices, the staff network should authenticate against a directory over RADIUS and 802.1X so that access follows identity rather than a passphrase circulating on a group chat. Where an organisation wants to control which devices are permitted onto the network at all, rather than only which people, network access control is the separate discipline that handles it.

One more note on roaming, because it is the complaint that arrives after everything else is fixed. Guests and staff walk. A device that clings to the access point it first joined, three rooms away, will show good signal statistics and deliver a poor experience, and no amount of central configuration compensates for access points placed too far apart. Roaming behaviour is tuned after installation with measurements taken while walking the building — the same route a guest takes from the lift to the room.

A concrete field example. A branch reports that the internet is unusable. The dashboard shows almost the entire circuit consumed by cloud file synchronisation on one workstation: somebody has just been added to a shared folder and is pulling down a few hundred gigabytes of archive. Without measurement that investigation takes a week and ends with a proposal to upgrade the circuit. With measurement the fix is a bandwidth limit on that application during business hours, and it costs nothing at all.

It also has to be said plainly that a dashboard is a live screen, not a monitoring system. Nobody watches it all day, and it does not remember to tell you anything. Monitoring means thresholds set deliberately, alerts routed to a person who is expected to respond, and an alert that is actually owned when it arrives. How that discipline is built is the subject of the network monitoring and ongoing management page, and it applies whether the underlying estate is cloud-managed or conventional.

None of these points make Meraki a bad product. What they do is change the nature of the decision: this is not a hardware purchase but a multi-year service commitment. The right question is not "is this a good device" but "can we carry this model for five years". Put five years of total cost on one side of the page and the cost of one person driving to nine branches on the other, and the answer generally settles itself — sometimes in Meraki's favour, sometimes against it. Either outcome is a good outcome, because it is a decision made with the numbers visible.

The lock-in point deserves expanding, because it is the least understood. Leaving a conventional estate, you hold configuration files; migrating to another vendor, you read them line by line and write the equivalent. Leaving a cloud-managed estate, that file does not exist. We compensate by keeping the design documentation vendor-neutral: the addressing plan, the VLAN table, the rationale behind each rule and the tunnel topology live in a document that exists independently of the dashboard, and it is maintained as the estate changes rather than written once at handover. While you hold those documents, an exit is painful but not impossible. Without them, an exit is a redesign with no starting point.

The cloud-dependency point is worth calibrating rather than dramatising. In practice, management-plane outages are infrequent and the data plane keeps forwarding through them, so most of the estate never notices. The risk that matters is narrower and sharper: if you need to make an emergency change during the same window in which management is unavailable, you cannot. For organisations where that specific scenario is unacceptable, the answer is not a workaround — it is a different architecture, and we say so.

The practical test we apply is this: how many times a year does somebody have to travel to a site, and what do those trips cost in travel, time and lost work? If that figure exceeds the licensing cost, cloud management pays for itself and the case is easy. If it does not, the same budget is better spent on stronger hardware and a disciplined configuration practice with proper version control and change records. We can deliver either. What we insist on is writing down, in the decision note, which one we chose and why.

It is also worth saying that the choice is not permanent or all-or-nothing. Several estates we look after run a mixed model: cloud-managed appliances at the branches, where the travel cost is real, and conventional hardware at head office, where an engineer is already present and the requirements are deeper. That arrangement carries its own overhead — two management approaches, two sets of documentation — but for some organisations it is honestly the best fit, and pretending otherwise serves nobody.

The step most often skipped is deciding what rollback actually looks like. The scene we meet in the field is familiar: the new appliance goes in, the old one is unplugged and thrown in a store cupboard the same afternoon, and when a problem surfaces at six in the evening there is nothing to fall back to. Leaving the old device physically in place, configuration untouched, for a week costs nothing and has rescued more cutovers than any amount of planning. There is no prize for clearing the cupboard quickly.

Ordering matters too, and the rule is simple: the most critical site is never first. Head office, the busiest hotel, the highest-turnover store — those go at the end of the list. The first site through is the most forgiving one, because something is always forgotten on the first cutover: a printer, a payment terminal, a device nobody could name that turns out to matter. You want that surprise to happen where it is cheapest, in front of a site manager who can afford to be patient about it.

Finally, keep the migration file as you go rather than assembling it at the end. Each site's verification list, the address ranges resolved, the exceptions granted and the reason for each one form the document a future team will read. Written during the work it takes minutes per site; reconstructed afterwards from memory it is both slower and less accurate, and the details that get lost are exactly the ones somebody will need at two in the morning.