NetXMS Support Forum

is there the possibility of having Sub Zones the use case is you can have a zone per customer with sub zones for each of there sites this would allow for easy management of which subnets are for which site but should allow for full map generation across the sub zones

Hi,

Sub zones aren't planned, and in practice you don't need them - a zone already carries its own ACL, so one zone per customer is your tenant boundary. Everything below it inherits those rights, so a user granted access to that zone sees that customer's subnets and nodes and nothing else.

What a zone isn't is a grouping level. It's an address space: it exists so two customers can both use 10.0.0.0/8 without colliding, and it carries the proxy set through which everything inside it is reached. Every node, interface and subnet stores a single zone UIN, not a path, so there is nowhere for a hierarchy to live. Nesting wouldn't mean anything either - an address is either unique within a space or it isn't.

So the two halves of what you're describing are handled separately.

Address space separation. One zone per customer is correct as long as that customer's own sites don't reuse addresses between themselves. If they do - every site running 192.168.1.0/24 - then you need a zone per site instead. Zones are flat, but nothing limits how many you create, and each one gets its own ACL.

Site organisation. That belongs in the Infrastructure Services tree: a container per customer, a container per site inside it, nodes placed by an auto-bind NXSL filter (by address range, sysLocation, custom attribute - whatever identifies the site). Use Collector instead of Container at the site level if you also want site-level data collection - it's a container that is itself a data collection target, so you can put aggregate DCIs and thresholds on it.

Important detail if you build that tree: access rights are OR-ed across all parents of an object. A node inside a customer zone that also sits in a shared container becomes visible to anyone who can read that container, zone ACL notwithstanding. Keep the customer's container subtree access-restricted the same way the zone is.

Note: auto-bind handles nodes always, and access points, clusters, collectors, mobile devices and sensors only when the matching Objects.<Class>.ContainerAutoBind server config is enabled - all of those are off by default. It never picks up Subnet objects. Subnets can be bound into a container, and binding is additive so the subnet stays in its zone tree as well, but you would do it by hand or from a scheduled NXSL script calling BindObject() on subnets by address range.

Maps already work across zones. Map content isn't zone-scoped anywhere. A map takes a list of seed objects, and a seed can be a container or collector - in that case every node underneath it becomes a seed. So one map per customer, seeded with that customer's container, covers all their sites no matter how many zones they are spread over. A zone itself is not a valid seed, so seed with containers or nodes.

Two details on how links get built on such a map. IP topology expansion from a single seed stays inside that seed's zone, because it walks the parent subnet tree and subnets are per-zone by definition. On L2, only LLDP resolves the neighbour globally (by LLDP node id, then MAC, then sysName) - CDP, NDP and OSPF look up the IP the neighbour reported inside the local node's zone. Neither is normally a problem, since two directly connected devices sit in the same zone anyway, and the map still spans zones through its other seeds and through VPN connectors.

Thanks for the reply and information