> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/5.1/planning-and-installation/bare-metal/manually-configure-the-weka-cluster-using-the-resource-generator/vlan-tagging-in-the-weka-system.md). # VLAN tagging in the WEKA system WEKA tenant clusters use VLAN tagging to enable isolated network communication between clusters and their clients. ## Overview WEKA support for IEEE 802.1Q VLAN encapsulation ("tagged VLAN IDs" or "tagged VLANs") enables isolation and segregation of network traffic while still granting connectivity between WEKA clients and backend servers. A WEKA tenant cluster operates on a single VLAN ID, where all containers within that cluster must use the same VLAN ID. All clients connecting to a tenant cluster must use that cluster's assigned VLAN ID. When using the WEKA Kubernetes Operator, this VLAN ID consistency between the tenant cluster and its clients is automatically maintained. In multi-cluster environments, each tenant cluster can operate on a different VLAN ID. For example, you can assign VLAN ID 100 to Tenant Cluster A and VLAN ID 200 to Tenant Cluster B, providing network isolation between clusters. {% hint style="info" %} Under [native multi-tenancy](/5.1/operation-guide/weka-native-multi-tenancy-management.md), each tenant's VLAN comes from its **network space** and is configured with `weka cluster network-space`, not through the procedure on this page. The cluster's **default network** — the one carrying backend communication and S3 protocol access — is a separate layer, and it *is* tagged by the procedure on this page. The two are independent: you can tag the default network, the tenant network spaces, or both. If you plan to use native multi-tenancy, set the default network's VLAN ID during deployment to a value that no network space will use, and configure the backend switch ports as trunks that carry the default network's VLAN and every network-space VLAN. {% endhint %} ## **Enable WEKA tagged VLAN support** To enable WEKA tagged VLAN support, add the desired VLAN IDs to the switch ports connected to WEKA backends. It is common to include one untagged VLAN and multiple tagged VLAN IDs. After configuring the switch, update the Linux system interfaces to recognize the VLAN IDs and verify connectivity. Use the following procedure on each WEKA backend and each WEKA stateful client. You do not need to perform this procedure on WEKA stateless clients because it is automatically applied during the mount command. **Procedure** 1. Associate the VLAN with the network interface using one of the following methods based on your naming preference: {% tabs %} {% tab title="Option A" %} Assign a tag to a specific device: `weka local resources net add --vlan ` Example: `weka local resources net add mlnx0 --vlan 501` {% endtab %} {% tab title="Option B" %} Add a dedicated VLAN interface where the tag is inferred from the name: `weka local resources net add vlan` Example: `weka local resources net add vlan501` {% endtab %} {% endtabs %} 2. Restart all containers on the server to apply the network configuration updates. ## Confirm which tagged VLAN is attached to the interfaces To determine which tagged VLANs are configured, query the local resources of a container using a command like this: ``` weka local resources -C ``` Example: ```bash weka local resources -C drives0 ``` You can also display the cluster container network data with this command by requesting verbose output with `-v` to list the VLAN ID or by using syntax like `-o id,hostname,name,ips,vlan`: ``` weka cluster container net -v ``` ## Mount filesystems with tagged VLANs When running a mount command on a WEKA stateless client where the backends have a tagged VLAN, specify the same VLAN in the mount command as follows: ### **Basic VLAN tagging** Mount a filesystem with a specified NIC and VLAN tag: ```bash mount -o net=/vlan@ ``` Example: ```bash mount -o net=mlnx0/vlan@501 10.10.0.10/default /mnt/weka ``` ### **Extended network configuration** Include gateway, IP, and netmask (in CIDR format) for advanced configurations: {% code overflow="wrap" %} ```bash mount -o net=/vlan@/gw@/ip@/netmask@ ``` {% endcode %} Example: {% code overflow="wrap" %} ```bash mount -o net=mlnx0/vlan@501/gw@192.168.1.1/ip@192.168.1.10/netmask@22 10.10.0.10/default /mnt/weka ``` {% endcode %} **Syntax guidelines:** * Include additional named parameters (for example, `gw@`, `ip@`, `netmask@`) directly in the command syntax. * Alternatively, use the legacy style by specifying name-value pairs after the positional parameters. * Separate all parameters using `/`. This syntax is also supported for the `weka local setup container --net ...` command. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.weka.io/5.1/planning-and-installation/bare-metal/manually-configure-the-weka-cluster-using-the-resource-generator/vlan-tagging-in-the-weka-system.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.