Capability

vTenant Virtualization

Run multiple tenants on a single TR7, each with its own resources, its own network and its own operational boundary.

TR7 vTenant Virtualization is designed to run multiple independent tenants on a single physical or virtual TR7. Each tenant is treated as a separate working zone with its own resource allocation, network context, disk space, management boundary and log/audit trail. This is not simply about creating different customer folders in the same interface. Tenants are separated across CPU, memory, disk, network interfaces, MAC address space, route and firewall contexts, and access permissions. MSPs, service providers, financial institutions, healthcare organizations and public-sector bodies can therefore run different customers or different security scopes side by side on the same TR7. On the network side, each tenant can use dedicated virtual interfaces, assigned resources and isolated traffic domains. A hardware-assisted interface assignment model — analogous to SR-IOV virtual functions — separates tenant traffic at the hardware layer; MAC prefix and slot structures prevent address conflicts. The result: TR7 vTenant Virtualization makes multi-customer and multi-security-domain operation manageable on a single device — not through soft configuration labels, but through genuine resource, network and operations isolation.

Maximum supported zones (tenants) — 6-bit zone field

Maximum interfaces per tenant — 5-bit interface field

Total address bit field — device + zone + interface

Separating tenants with folders alone is not real isolation.

In MSP and service provider environments, deploying a separate appliance for every customer is expensive, operationally complex and inefficient in terms of capacity. But running all customers on one device with only name or folder separation is not sufficient either. Unless traffic, logs, networking, resources and permission boundaries are clearly divided, tenants can affect one another.

In compliance-driven environments the stakes are even higher. When different security scopes — PCI, healthcare data, classified government workloads — share the same physical hardware, it must be provable which tenant can access which resources, which network segments and which logs. Software-based labelling alone rarely provides that assurance.

Resource consumption in multi-tenant deployments also generates operational risk. One tenant's connection count, traffic load, log volume or misconfiguration must not degrade the performance of others. This is why CPU, memory, disk, network interfaces and flow limits need to be planned at the per-tenant level.

The right approach is to treat each tenant as its own working zone — separating resources, network, logs, audit trails and management permissions by tenant boundary. Tenant isolation must be enforced not only at the UI layer, but at the traffic and resource planes as well.

TR7 vTenant Virtualization delivers this model: it makes resources, network and operations boundaries separately manageable when running multiple tenants on a single TR7.

Our approach

TR7 vTenant architecture is built around per-tenant independent working zones, assigned network resources, isolated traffic contexts and resource quotas.

Each tenant is treated as a separate working zone

A vTenant is an independent working zone inside a single device, with its own management and traffic boundary. Each tenant's services, network context, logs and resource settings are used in isolation from all other tenants.

Per-tenant dedicated network interfaces and traffic domains

Physical interfaces can be shared across tenants using dedicated virtual functions or slot structures. Each tenant receives and sends traffic over its own network surface, with no commingling with other tenant traffic.

Network context is separated at the tenant level

Each tenant can have its own IP space, routing table, firewall context and interface view. The same IP ranges can be used in different tenants without conflict, and traffic is evaluated within its own tenant context.

CPU, memory, disk and flow limits are assigned per tenant

Processor cores, memory, disk space and connection or flow limits can be planned for each tenant individually. This model prevents one tenant's resource consumption from affecting others.

Capabilities

vTenant Virtualization separates multi-tenant structures across resource, network, identity, log and operations dimensions.

Per-tenant independent working zones provide multi-customer isolation

Each vTenant is managed as a distinct working zone. The vServices, certificates, rules, network configurations and log structures defined within a tenant remain within its own boundary. MSPs and service providers can operate different customers side by side on the same TR7. This model reduces the number of physical appliances while preserving operational isolation.

Tenant lifecycle covers start, stop and restart flows

Each tenant can be managed with independent lifecycle behavior. A tenant can be started, stopped, restarted or configured to start automatically. This ensures that maintenance on one tenant does not affect others. Operations teams can execute per-customer or per-environment maintenance windows without disrupting the platform.

A bandwidth slice per tenant that is there at every moment

A tenant is given a fixed share of the appliance's capacity, taken from the device total when the tenant is created, and the enforcement happens on the appliance itself rather than in a spreadsheet. The share is deliberately not work-conserving: an idle tenant's bandwidth is not lent to a busy neighbour, so what you sold is available the second the customer asks for it — predictability before utilisation. Traffic is paced rather than dropped, so a tenant at its ceiling slows down instead of losing packets.

Per-tenant CPU core assignment reduces resource noise

TR7 can plan the assignable CPU core pool for tenants after accounting for cores reserved for the host. More processor resources can be allocated to critical tenants; lower-traffic tenants can operate with more constrained allocations. This prevents heavy customer traffic from affecting the control plane of other tenants. Resource management becomes part of capacity planning.

Per-tenant disk allocation strengthens data and log separation

A separate working disk and raw data space can be reserved for each tenant. Deployments can start from default values and scale tenant allocations as demand grows. Logs, reports, configuration and temporary data are kept within the tenant boundary. This structure is important for compliance and operational data separation requirements.

Hardware-assisted interface assignment isolates tenant traffic

Virtual functions from physical network interfaces can be assigned to tenants. Each tenant sends and receives traffic over its own interface slot. This approach provides stronger traffic separation than software-based labelling. In high-traffic tenants, performance and isolation are maintained together.

Interface trust and spoof control governs tenant network behavior

Trust and spoof-check settings can be managed on interfaces assigned to a tenant. This keeps the tenant's MAC and traffic behavior within expected bounds. In multi-tenant networks, incorrect or conflicting address behavior is brought under control early. Network security becomes a natural part of the tenant boundary.

MAC prefix and slot model prevents address conflicts

TR7 can generate unique MAC addresses for tenant interfaces using a macprefix and slot structure. The model combines a 3-byte prefix with tenant and slot information to produce consistent, conflict-free addressing. When many tenants and interfaces are defined on the same device, collision risk is reduced. Network teams can track tenant interfaces more readably.

Zone and interface bit fields enable scaled tenant planning

TR7 uses device, zone and interface bit fields to plan tenant and interface capacity. A 6-bit zone field supports addressing for up to 64 tenants; a 5-bit interface field supports up to 32 interfaces per tenant. This structure provides orderly scaling in large MSP and multi-environment deployments. Tenant growth is bound to a predictable capacity model from the outset.

Separate network context supports route and firewall isolation

Each tenant can have its own IP space, routing table, firewall rules and interface view. The same private IP ranges can be used in different tenants without conflict. This reduces the classic RFC1918 address-overlap problem in multi-customer environments. Traffic is evaluated within the tenant context and does not cross into the wrong network domain.

Per-tenant log and audit visibility reduces data exposure

Each tenant's log and audit stream is handled separately; one tenant's operational records are not visible to another. This separation is critical for customer privacy, compliance and incident investigation processes. At the central management level, authorized users can perform tenant-scoped reporting.

Internal command execution supports tenant lifecycle and diagnostics

Lifecycle, health and diagnostic operations can be performed by sending controlled commands into a tenant. This allows issue investigation or maintenance to be conducted within a specific tenant without affecting the entire device. Command permissions can be scoped through RBAC and audit controls. Support teams can diagnose issues faster within the tenant context.

Central management and RBAC make tenant visibility auditable

Central Management can view and manage tenants across multiple TR7 devices in aggregate. RBAC constrains which users can see or modify which tenants. In MSP scenarios, per-customer permission separation can be enforced within the same management interface. Management convenience and tenant privacy are preserved within the same model.

Operational depth

vTenant operation works in conjunction with default disk values, CPU planning, bit fields, the management IP model, interface assignment and MAC address generation.

Default disk plan

A default working disk and raw data space can be defined for each tenant. Default values of 20 GB for the working disk and 30 GB for the raw data space allow fast initial provisioning; capacity can be increased per tenant as production load grows. Log and report volume should be factored into disk planning separately.

CPU resource calculation

The assignable core pool for tenants is formed by subtracting the cores reserved for the host from the total core count. More cores can be assigned to critical tenants. This model combines resource isolation with capacity planning.

Bit field capacity

Device, zone and interface bit fields together form a 12-bit addressing model. The 6-bit zone field provides capacity for 64 tenants; the 5-bit interface field provides capacity for 32 interfaces per tenant. These values clarify the scale plan for large deployments.

Tenant management IP

A local IP for management purposes can be generated for each tenant. This IP is used in tenant lifecycle, health and internal management flows. Management traffic should be handled separately from tenant data traffic.

Interface slot model

Assigned interfaces on a tenant can carry slot number, virtual function count, MAC space and MTU information. This model allows physical network resources to be distributed to tenants in an orderly fashion. Network impact should be evaluated carefully before modifying the slot plan.

MAC prefix generation

Unique MAC addresses can be generated by appending tenant and slot information to a 3-byte macprefix. This structure reduces address conflicts and makes it easier to track which interface belongs to which tenant. It provides readability for network operations.

When to use it

Multi-customer MSP operation on a single TR7

A service provider can run 30 customers as separate vTenants. Each customer has its own network, logs, rules and resource space; operations are simplified on a single device.

PCI scope separation by tenant in banking

A cardholder data tenant and a corporate web traffic tenant can operate as separate working zones on the same TR7. Resource, network and audit separation strengthens compliance evidence.

Isolated dev and prod environments in healthcare

Healthcare organizations can keep test, development and production traffic in separate tenants. Production patient data and development traffic are managed from the same operations panel while remaining isolated from each other.

Classified and public service separation in government

Government bodies can run services at different security levels in separate tenants. Network, log and access permissions are separated per tenant, reducing the risk of unauthorized access.

Three-tenant test, staging and production setup

Test, staging and production tenants can be created on the same TR7. Application changes are validated with equivalent ADC/WAAP behavior before being promoted to production.

Frequently asked questions

What is the difference between vTenant and classic software-based multi-tenancy?

In classic software multi-tenancy, separation is usually at the UI or configuration label level, while CPU, memory, disk and network resources are drawn from a shared pool. With vTenant, CPU cores, disk space, network interfaces and traffic context are planned separately for each tenant. Hardware-assisted interface assignment and the MAC prefix structure move traffic separation below the software layer. This distinction is critical for proving isolation in compliance-driven environments.

How many tenants can run simultaneously?

TR7's bit-field architecture supports addressing for up to 64 tenants through the 6-bit zone field. In practice, the number of running tenants depends on the available physical resources — CPU cores, total memory and disk. In large MSP deployments, tenant counts and resource quotas are established through capacity planning.

Is a dedicated network interface required for every tenant?

It is not mandatory, but hardware-assisted virtual function assignment strengthens traffic isolation. Tenants without assigned interfaces can use namespace-based network separation. For high compliance requirements or high-traffic scenarios, hardware-assisted interface assignment is the preferred approach.

Does maintaining one tenant affect others?

No. Each tenant is managed with independent lifecycle behavior. A tenant can be stopped, restarted or placed into maintenance mode while other tenants continue running without interruption. This model simplifies per-customer maintenance window management in MSP environments.

How does vTenant log and audit separation work?

Each tenant's log and audit stream is handled separately; one tenant's operational records cannot be seen by another. Authorized users at the central management level can perform tenant-scoped reporting. RBAC constrains which user can access which tenant's logs. This structure is important for customer privacy and compliance requirements.

How does vTenant work with Central Management?

Central Management can view and manage tenants across multiple TR7 devices in aggregate. RBAC configuration constrains user access to specific tenants. In MSP scenarios, per-customer permission separation can be enforced within the same management interface. Central visibility and tenant privacy are preserved simultaneously.

Build your multi-tenant environment on a single TR7

Tenant architecture for MSP, banking, healthcare and government — with resource, network and operations isolation. Let's walk through a live setup on your own deployment.