Zones & tiers
The two keys that shape every Marrow diagram — how they interact, when to use which, and how nesting and collapse behave.
zone and tier are the load-bearing keys. Almost every "why does my diagram
look like that?" traces back to one of them being missing, wrong, or fighting
the other.
They are orthogonal. A device can have both, either, or neither.
Tiers
Six values, ranked top to bottom on the page:
| Tier | Rank | Typical use |
|---|---|---|
edge | 0 | WAN routers, perimeter firewalls, internet handoff |
core | 1 | L3 core, spine |
distribution | 2 | Aggregation, leaf |
access | 3 | Access switches, ToR, APs |
endpoint | 4 | Servers, workstations, phones, IoT |
management | 4 | OOB, jump hosts, monitoring |
endpoint and management share rank 4 — they sit on the same row.
Tiers only take over the layout when every device declares one. A single
device without a tier drops the whole topology out of tiered classification.
That is the single most common surprise. If your three-tier network came out
looking flat, run down the device list looking for the one that's missing tier:.
Zones
A zone is a container drawn as a tinted panel with a title. Its contents are laid out on their own and then packed against the other zones.
Two or more zones containing devices switches the layout to the zoned mosaic, and that outranks tiers. Inside each zone, tiers still order devices vertically — so zones and tiers compose rather than compete. Zones decide the big shape; tiers decide the shape within.
Use zones for things that are genuinely somewhere: sites, buildings, floors, VLANs, VPCs, OT versus IT, DMZ versus internal. Don't use them as a tagging system — a zone with two devices in it is a box that costs more than it explains.
Nesting
parent nests zones arbitrarily deep. Cycles are an error (MRW-E016).
On a multi-page site, only top-level zones get their own page; a page covers its whole subtree. So the nesting level you choose determines the page granularity of the built site.
Collapse
| Value | Behavior |
|---|---|
auto (default) | The engine decides from the zone's size |
open | Always expanded |
closed | Always collapsed to a summary tile with a device count |
closed is how you keep a huge but uninteresting zone (500 desktops) from
dominating a diagram that's actually about the core.
Choosing between them
| Situation | Reach for |
|---|---|
| Classic three-tier campus, one site | Tiers only |
| Several buildings or sites | Zones (+ tiers inside each) |
| Cloud VPCs / subscriptions | Zones per VPC or account |
| Hub-and-spoke WAN, many branches | Neither — let hub-spoke classification take over |
| OT/IT segmentation, DMZ | Zones — the boundary is the point |
| One flat lab of 8 boxes | Neither |
Common failures
"My zones didn't render as panels." You need two or more zones that actually contain devices. One zone is not a mosaic; the engine ignores it as a layout signal.
"Everything is in one column." Every device probably landed in the same tier, or none declared a tier and the fallback flat layout kicked in.
"My HA pair is on opposite sides." ha_pair_with needs to be on both
devices. Also check they're in the same zone — the engine won't pull a device
out of its declared zone to sit next to its partner.
"A zone panel is enormous and empty." An empty zone raises MRW-W102. Either
put devices in it or delete it.
Meaning is declared, never guessed. The engine will not read
core-sw-01 and conclude the device is core, and it will not infer that
dc1-* devices belong together. If you want structure, say so.
Next: how layout is chosen.