Enhanced site separation¶

Big organisations often run one tenant with many sites, each with local IT that runs its own site - and must not touch anyone else's. Enhanced site separation makes each site behave like a mini-tenant for site-scoped users, while HQ (admins and users with cross-site grants) keeps full visibility and control.

It's off by default. Turn it on under Settings → Separation → Site separation: the page opens on the install-wide default, and its This tenant scope carries the override.

Who counts as "site-scoped"¶

A user whose write permissions all carry a sites limit - the shape the Site editor role creates. Admins, superusers, and anyone holding an unscoped write grant are never affected by this mode.

What it changes¶

With the switch off, the write boundary is already enforced: a site-scoped editor can't create, move, or bulk-edit objects into a foreign site - the server rolls such writes back. The mode adds strictness and ergonomics on top:

Which rows belong to a site¶

A row belongs to a site through its own site, or through the object it hangs off:

• an IP address - its own site, else its prefix's. An address inside Site B's prefix is Site B's even when the prefix doesn't copy its site onto addresses; only an address in a site-less prefix is shared;
• a service - its device's or VM's site, else its address's;
• NAT rules, virtual chassis, site-map markers - their device's (the master's, for a virtual chassis);
• IP ranges, DHCP scopes - their prefix's; DHCP reservations and leases, their scope's prefix's;
• VLAN groups - their site, else their cluster's;
• circuit terminations - their own site, else the site of the VM whose interface they land on;
• FHRP group assignments, tunnel and L2VPN terminations - their interface's device or VM (an L2VPN's VLAN, for a VLAN termination);
• routing rows - BGP address families, redistributions and IGP interfaces, their instance's device or VM; VTEP memberships, their VTEP's device;
• virtual disks, virtual switches - their VM's, their cluster's;
• DNS records and drift, certificate bindings - their IP address's;
• config snapshots and state, BMC endpoints, port-utilization rules, Zabbix host links and pending changes, virtualization changes - their device's or VM's.

A site-limited grant narrows all of these, for reading and writing. Types that only refer to a site-bound row stay tenant-wide: FHRP groups, wireless LANs, prefix-list rules, notification channels, virtualization networks and placement rules, Zabbix connections and adoption rules. Check assignments, monitoring policies, alert rules and silences follow the object they target.

Circuits, tunnels and L2VPNs are tenant-wide, but their ends are not: a circuit, tunnel or L2VPN lists only the terminations the reader may view.

Creating prefixes: your space, or a fresh one¶

A site editor can create prefixes two ways:

1. Carve inside your own site's space - allocate a child of any prefix already assigned to your site. This is the normal "here's your /18, subnet it however you like" flow.
2. Stand up a brand-new range that collides with nothing - a dark or non-routed subnet (say a private 192.168.50.0/24 for an isolated lab). As long as it overlaps no existing prefix - not the shared/global space, not another site's - it's allowed and stamped to your site.

What you can't do is overlap someone else's space: carving inside the shared (site-less) supernet, or inside another site's range, is refused with a clear message. That's what keeps a site's "dark" ranges from colliding with the global plan.

Local vs global catalog entries¶

Catalogs - tags, device types, manufacturers, statuses, IP roles, VRFs, route targets, custom fields, zones - are shared per tenant. With separation on, they gain a locality dimension so a site can't "fix" (break) what every other site relies on:

• Every catalog entry is either Global (usable everywhere, badge "Global") or Local - \<site> (visible and usable only within that site).
• A site-scoped user sees global entries plus their own site's local ones; other sites' local entries don't exist for them.
• They can edit or delete only their own local entries - global entries are read-only, and referencing them (a device on a global device type, a global tag on a prefix) is always fine.
• Anything they create becomes local to their site automatically - including device types imported from YAML (and any manufacturers the import mints along the way).
• Promote / re-home: tenant-wide editors (HQ, admins) can promote a good local entry to global, or assign a global one to a site, from the entry's detail page.
• VLANs use their existing site field as locality: HQ pushes site-less (shared) VLANs everyone can read; sites create their own.

With separation off, the locality stamp is kept but not enforced - catalogs behave tenant-wide exactly as before.

The site roles read the catalogs their objects use, a silo editor and a viewer included: with separation on, global entries and their own sites' local ones; with it off, the tenant's whole catalog. Catalogs without locality - device roles, platforms, rack and cabinet types, and the like - read tenant-wide either way.

Rollout notes¶

• The tenant override is its own group - overriding separation does not detach the tenant from deployment defaults for sharing or UI policy.
• Flipping the switch off restores the default behaviour exactly; nothing is migrated either way.
• The companion switch "Let site admins manage their site's settings" unlocks the This site scope on Settings → Email: local IT overrides their site's mail relay (more groups later). A site admin is a site editor of that site, or anyone holding a sitesettings permission scoped to it - grantable to users or groups, so you can build a "Site X admins" group. Tenant admins can always edit any site's settings. Site alerts about that site's objects then use the site relay; sign-in codes and digests stay tenant-level.