Network Ports
Network ports (also called target ports or network interfaces) are the Ethernet interfaces through which a QuantaStor system is managed and through which it serves storage. This page covers how to address a port, how to combine ports into a bond, how to layer VLAN and virtual interfaces on top of a port, how to control which protocols each port carries, and how to add static routes.
Client hosts reach Storage Volumes over iSCSI and NVMe-oF/TCP through a network port, authorized users reach Network Shares over NFS and SMB through a network port, and object storage buckets are reached over S3 through a network port. Every one of those paths depends on the port configuration described here, so it is worth getting right before you provision storage.
| Section | Purpose |
|---|---|
| Port types and naming | How to tell a physical port, a bond, a VLAN, a VIF and a cluster VIF apart by name. |
| Where network ports are managed | The tabs, toolbar and right-click menu that hold every port operation. |
| Static vs DHCP assigned IP addresses | Why static addressing is required in practice, and the one-time conversion on a fresh install. |
| Modifying network port settings | Every field on the General Settings tab of Modify Network Port. |
| Firewall settings per port | Allowing and blocking individual protocols on one port. |
| NIC bonding and trunking | Combining ports for throughput and fault tolerance, and which bonding mode to pick. |
| VLAN interfaces | Tagged virtual ports on a physical or bonded port. |
| Virtual interfaces | Extra IP addresses on one port. |
| High-availability and cluster virtual interfaces | Floating IPs that move with a pool, a site or the grid. |
| Renaming a network port | Giving a port a stable, meaningful name. |
| Online, offline, restart and rescan | Bringing a port up or down and picking up out-of-band changes. |
| Static route management | Routing specific networks through a gateway other than the default. |
| Choosing which ports carry which traffic | Separating management traffic from storage traffic. |
| Verifying connectivity | The Network Check report. |
| Command line reference | The qs commands that cover everything on this page.
|
Port types and naming
QuantaStor names every port after the interface the kernel presents, and uses two delimiters to indicate that a port is layered on top of another one. Reading the name tells you what a port is:
| Name | Type | Notes |
|---|---|---|
ens192, eno1, enp3s0f0 |
Physical port | The predictable name assigned by the kernel. Rename it if you want something more meaningful -- see Renaming a network port. |
bond0 |
Bonded port | Two or more physical ports combined. The member ports become slaves and stop carrying their own IP address. |
ens192.56 |
VLAN interface | A period separates the parent port name from the VLAN tag. A VLAN on a bond looks like bond0.56.
|
ens192:1 |
Virtual interface (VIF) | A colon followed by an index, allocated from 1 upwards. An extra IP address on the parent port. |
ens192:ha345680 |
HA pool virtual interface | Floats with a storage pool when the pool fails over. |
ens192:sv... |
Site cluster virtual interface | Floats between the appliances of a site cluster. |
ens192:gm |
Grid management virtual interface | The single floating IP a storage grid is managed through. iSCSI and NVMe-oF are permanently disabled on it, because a management IP that moves on failover is not a safe place to export block storage from. |
ens192 (S) |
Manually configured secondary port | An address that QuantaStor discovered but does not own. Management operations are refused on these. |
Interface names are limited to 15 characters by the kernel, and the tag QuantaStor appends when it creates a cluster virtual interface has to fit inside that budget. A long parent port name is therefore not merely untidy -- it will eventually block cluster VIF creation, so keep renamed ports short.
Where network ports are managed

Select the Storage Systems section in the tree on the left, then the Network Ports tab in the centre of the screen. The tab lists every port on every system in the grid, grouped by storage system, with its state, link state, link speed, IP address, subnet mask, whether it is an iSCSI or NVMe-oF portal, and its vendor, model, MAC address, byte counters and MTU. The Network Static Routes tab beside it lists the static routes on those same ports.
The Network Port toolbar group at the top of the screen carries Modify, Create Virtual Port, Create VLAN Port, Create Bonded Port, the matching Delete operations, Online, Offline and Rescan All.

Three operations are reachable only by right-clicking a port, not from the toolbar: Rename Network Port..., Restart Network Port... and Create Static Route... / Delete Static Route.... Right-click a port either in the tree on the left or in the Network Ports tab.
For grid-wide settings such as the DNS servers and search domain that apply to all ports, use Modify Grid Network Settings instead -- the Modify Grid button in the Storage System Grid toolbar group. It writes one DNS search suffix, DNS server list and NTP server list to every system you tick, overwriting whatever those systems had. The per-system equivalents are the DNS Servers and NTP Servers tabs of Storage System Modify.
Static vs DHCP assigned IP addresses
QuantaStor supports both statically assigned IP addresses and dynamically assigned Dynamic Host Configuration Protocol (DHCP) addresses. After installation the first port is typically configured by DHCP and the rest are disabled, so that the appliance is reachable for initial setup.
Reconfigure every port with a static IP address before you provision storage. A DHCP lease can change, and a storage system whose address moves takes its iSCSI targets, NFS exports and SMB shares with it. The appliance also has to be able to boot and serve storage when the DHCP server is unreachable. The only defensible use of DHCP is a reservation that always hands the same address to the same MAC, and even then a static address is simpler to reason about.
There is a second, one-time reason to set a static management address first. A freshly installed system still has the installer's netplan configuration active. The first time you modify any network port, QuantaStor converts that configuration into /etc/network/interfaces, backs up the previous file as /etc/network/interfaces-netplan-convert-<timestamp>.backup, renames each /etc/netplan/*.yaml file to .bak, and disables the netplan renderer. All interfaces are torn down and brought back during that conversion, so a port still on DHCP can come back with a different address and the management session drops. QuantaStor guards against this: while any port is in that state it is flagged with a warning whose detail begins "Netplan", and the Modify Network Port dialog refuses any change other than to static, with the message "Be sure to configure a static management network port before modifying network ports."
Set a static address on your management port first, then work through the remaining DHCP ports until they all have static IPs assigned. Reboot afterwards and confirm the configuration, which is what the accompanying alert asks for. This is an important step after an initial QuantaStor OS installation as this allows the system to cleanup network configuration issues left behind by the text mode installer.
Modifying network port settings

The dialog is also on the Modify button in the Network Port toolbar group. It has two tabs, General Settings and Firewall.
General Settings
| Field | Description |
|---|---|
| Storage System | The system whose port you are configuring. Changing it reloads the Network Port list. |
| Network Port | The port to modify. Every port on the selected system is offered, including bonds, VLANs and virtual interfaces. |
| Config Type | static, dhcp or disabled. Only static enables the Static IP Configuration Settings fieldset below. Choosing disabled prompts for confirmation and then removes the port's stanza from /etc/network/interfaces entirely, so the port stops carrying traffic and does not come back after a reboot. A port that is a bond slave reports as disabled and cannot be changed here -- delete the bond first. Cluster virtual interfaces are locked to static because the cluster software owns their addresses.
|
| Description | An optional note recorded against the port. Use it to record what the port is for; there is no other place to do that. |
| iSCSI Portal | Makes this port's IP address an allowed iSCSI portal. Clearing it removes the address from the allowed-portal list of every iSCSI target on the system, so initiators can no longer log in through it. Existing sessions are not torn down -- the change takes effect on the next login. If no port at all is left iSCSI-enabled, QuantaStor restricts iSCSI to loopback rather than leaving it open. |
| NVMeoF Portal | Makes this port's IP address an NVMe-oF/TCP listener on port 4420. Unlike the iSCSI setting, clearing it removes the listener, which does drop connections through that address. |
| Lossless Networking | Configures RoCEv2 with priority flow control on the port. Only selectable on adapters that support it -- in practice Mellanox/NVIDIA ConnectX cards with RDMA enabled -- and greyed out everywhere else. It sets DSCP-based priority trust, enables PFC on priority 3 only, turns global pause off, sizes the receive buffers for the adapter model, and records the port in /var/opt/osnexus/quantastor/conf/qs_losslessNetworking.conf. QuantaStor verifies the result and reverts the change if verification fails. Enable it only where the switch fabric is configured for the same priority flow control scheme; a one-sided configuration performs worse than plain Ethernet.
|
| Optimize hardware RX/TX buffer settings for throughput | Enlarges the adapter's receive and transmit ring buffers. QuantaStor records the current sizes so it can put them back, then raises both rings to the largest power-of-two multiple of 128 that still fits under the adapter's hardware maximum -- roughly half the maximum, which improves large-block and replication throughput without asking the driver for a size it will reject. Settings are recorded in /var/opt/osnexus/quantastor/conf/qs_porttunings.conf and re-applied every five minutes. Available on physical ports only: a bond, VLAN or virtual interface has no hardware ring of its own, so enable it on the member ports instead.
|
The Static IP Configuration Settings fieldset holds the addressing:
| Field | Description |
|---|---|
| IP Address | The static address for the port. Each port needs a unique address; QuantaStor rejects an address already recorded on another port. If the address is part of a Ceph cluster configuration you have to disable the port before the address can be changed. |
| Subnet Mask | The mask for the port's network, such as 255.255.0.0.
|
| Gateway | Optional. QuantaStor checks that the gateway is on the same subnet as the port address and refuses it otherwise. Configure a gateway on one port only. QuantaStor gives every static port the same route metric, so a second gateway-bearing port ends up competing for the default route rather than adding a fallback. |
| MTU and Jumbo Frames | The maximum transmission unit, 1492 to 64000. The Jumbo Frames button toggles between 9000 and 1500 and relabels itself Default Frames once jumbo is set. Set 9000 on all 10GbE and faster interfaces. If you move away from 1500, the switch ports and the client hosts on that network have to match -- a mismatched MTU produces intermittent stalls rather than a clean failure. The field is disabled for VLAN and virtual interfaces, which inherit the parent port's MTU; changing the parent cascades the new MTU to all of its children. Setting a VLAN MTU above its parent's is capped to the parent's value with an alert. |
Changing the IP address of a port that has static routes configured is flagged: the routes are bound to the old address and client connections through them can drop. Remove the routes first.
Click Apply to commit the change and keep the dialog open, or OK to commit and close.
Firewall settings per port

The Firewall tab lists each service QuantaStor knows how to filter, with its description and a Status setting. The three settings are what makes this useful, and the distinction is easy to miss:
- Inherit -- follow the system-wide firewall setting. This is the default for every service on every port.
- Block -- drop traffic for this service arriving at this port's IP address, even though the system-wide setting allows it.
- Allow -- accept traffic for this service at this port's IP address, even though the system-wide setting blocks it.
So the system level sets the policy and the port level carries the exceptions. The usual pattern is to block everything you do not use at the system level -- see Firewall Management -- and then Allow the handful of protocols each port is actually meant to serve.
Two things are worth knowing before you rely on it. The rules match on the port's destination IP address, not on the interface, so a per-port rule really follows the address; that is deliberate, and it is why the masks are also recorded against HA and site virtual interfaces so the rule follows a floating address to whichever system holds it. And because QuantaStor reports a service as blocked whenever any DROP rule exists for it, blocking a protocol on one port raises an alert saying that service is blocked system-wide, even though only that one address is affected.
The service list, the TCP and UDP ports behind each entry, and the bit each one occupies come from /opt/osnexus/quantastor/conf/qs_services_firewall.conf on the appliance. The rules themselves are iptables rules in QuantaStor's own chains (QUANTASTOR-INPUT, QUANTASTOR-FORWARD, QUANTASTOR-OUTPUT), written out to /var/opt/osnexus/quantastor/iptables.qsfirewallrules so they survive a restart, and kept out of the shared chains so the firewall can be rebuilt without disturbing other rules on the system. QuantaStor re-applies them on change and again every 20 minutes.
Changing a setting that makes a service unreachable prompts for confirmation first. For the complete list of TCP and UDP ports QuantaStor and its supporting services use, see Network Port Usage.
The same firewall settings can be driven from the CLI with qs network-port-modify --protocol-block= and --protocol-allow=, each taking a comma-separated protocol list, with --protocol-block-reset and --protocol-allow-reset to clear a list. Prefix a protocol with a tilde (~) to remove it from a list rather than add it.
NIC bonding and trunking

Bonding, also called trunking or teaming, combines several physical ports into one logical port to improve throughput and to survive the loss of a cable, a switch port or a NIC. The bond takes the IP address; the member ports become slaves and no longer carry addresses of their own.
For every mode except LACP, all of the member ports must be connected to the same switch. LACP works across switches -- which is what makes it the only mode that survives a whole switch going away -- but it requires the switch ports to be configured for LACP as well. QuantaStor surfaces switch-side mistakes on the port itself, reporting an invalid partner MAC address or a partner that is not advertising LACP support, so check the port state after creating an LACP bond rather than assuming it came up.
The dialog fields are the same addressing fields as Modify Network Port, plus:
| Field | Description |
|---|---|
| Bond Mode | The bonding policy. See the table below. |
| Select the Network Ports to be Bonded | Select at least two ports. The grid lists each candidate port's name, IP address, vendor and model. |
| Hide Configured Ports | Selected by default, hiding ports that already have an IP address so you do not accidentally bond your management port. Clear it to bond a configured port; QuantaStor warns that the port's existing IP configuration will be removed and that the bond will only have the address you entered. |
| Force | Proceeds without the confirmation prompt when a selected port already has an IP configuration. |
The modes QuantaStor offers, with the switch requirement each one carries:
| Mode | Kernel mode | Switch | Behaviour |
|---|---|---|---|
| Link Aggr Ctrl Protocol (LACP layer2) | 802.3ad, hash layer2 |
Managed, LACP configured | Balances by source and destination MAC. Spans switches. Recommended default. |
| Link Aggr Ctrl Protocol (LACP layer2+3) | 802.3ad, hash layer2+3 |
Managed, LACP configured | Adds the IP addresses to the hash, which spreads traffic better when many clients sit behind one router MAC. |
| Link Aggr Ctrl Protocol (LACP layer3+4) | 802.3ad, hash layer3+4 |
Managed, LACP configured | Adds the TCP/UDP ports to the hash, so a single client with many connections can use more than one member link. |
| Round Robin (balance-rr) | balance-rr |
Etherchannel, managed | Sends packets in sequence across the members. Highest single-stream throughput, but it reorders packets and does not span switches. |
| Adaptive Transmit Load Balancing (balance-tlb) | balance-tlb |
Unmanaged | Balances outbound traffic only; inbound arrives on one member. Needs no switch configuration. |
| Adaptive Load Balancing (balance-alb) | balance-alb |
Unmanaged | As balance-tlb, plus inbound balancing via ARP negotiation. Needs no switch configuration. |
| Balance XOR (balance-xor) | balance-xor |
Etherchannel, managed | Picks a member by hashing the MAC addresses. Static, so both ends must agree. |
| Active-Backup (active-backup) | active-backup |
Unmanaged | One member carries all traffic; the others stand by. No throughput gain, and the simplest mode to get right. |
For fault tolerance that survives a switch outage, LACP is the mode to use. Where the switches are unmanaged and cannot be configured, use Active-Backup or one of the adaptive load balancing modes.
The Bond Mode combo in the Create Bonded Port dialog is pre-selected from the storage system's own default bonding policy, which QuantaStor sets on first startup and records in /etc/modprobe.d/bonding.conf. On the 6.9.0 system this page was verified against that default was LACP layer 2. Check yours with qs system-get and look at the Bond Mode field, and change it with qs system-modify --bond-mode=<mode>. QuantaStor sets miimon=100 on every bond so link failures are detected within a tenth of a second, and allows a maximum of four bonds per system.
To change the mode of a bond that already exists, open Modify Network Port on the bond and use the Bond Port Advanced Settings... button, which appears only when the selected port is a bond. The mode cannot be changed while the bond is carrying a virtual interface or an HA virtual interface -- remove those first. If a member port drops out of a bond, QuantaStor re-enslaves it automatically, at most once an hour per member.
Delete a bond with Delete Bonded Port in the toolbar, or qs bond-delete --port=<bond>. The member ports return to being unconfigured physical ports.
VLAN interfaces

A VLAN (Virtual LAN) interface is a virtual port that tags its traffic with a VLAN ID, letting one physical or bonded port serve several isolated networks. VLAN interfaces can be created and deleted at any time.
| Field | Description |
|---|---|
| Storage System | The system to create the VLAN interface on. |
| Parent Port | The physical or bonded port to tag on. A VLAN cannot be created on another VLAN, nor on a virtual interface, so those are filtered out of the list. |
| IP Address, Subnet Mask, Gateway | The addressing for the VLAN interface, on the network that VLAN reaches. |
| Description | An optional note. Recording which network the tag corresponds to pays for itself. |
| MTU | Read-only. A VLAN inherits the parent port's MTU; change it on the parent. |
| VLAN ID | The 802.1Q tag, 1 to 4094 (4095 is reserved). Defaults to 5. |
| VLAN QoS | The 802.1p Class of Service user priority to record for the interface, 0 (lowest, the default) to 7 (highest). |
The new port is named after its parent with a period and the tag, so VLAN 56 on ens192 becomes ens192.56 and VLAN 56 on bond0 becomes bond0.56. Delete a VLAN interface with Delete VLAN Port in the toolbar or qs vlan-delete --port=<port>. A port that has a VLAN child cannot be disabled or renamed until the VLAN is removed.
Virtual interfaces

A virtual interface (VIF) gives a physical or bonded port an additional IP address, so one port can be present on several networks or carry several addresses on the same network. VIFs can be created and deleted at any time, and cannot be layered on top of another VIF.
The fields are Storage System, Parent Port, IP Address, Description, Subnet Mask, Gateway, and a read-only MTU inherited from the parent port. QuantaStor names the new interface after the parent with a colon and the next free index, so the first VIF on ens192 is ens192:1.
Two constraints are not obvious from the dialog. A VIF cannot be created on a bond running in Active-Backup mode. And DHCP is not valid on a virtual interface -- a VIF is always statically addressed.
Delete a VIF with Delete Virtual Port in the toolbar or qs vif-delete --port=<port>.
High-availability and cluster virtual interfaces
QuantaStor also has virtual interfaces that float between systems. You will see these with :ha, :sv or :gm in the name, such as ens192:ha345680.
- HA pool virtual interfaces (
:ha) are associated with a specific storage pool and move with the pool when it fails over to another system. A pool can have several; each additional one increments the last digit of the port name, so they run:ha345680,:ha345681,:ha345682and so on. Create them by right-clicking an HA failover group in the Storage Pools section and choosing Add Cluster VIF..., or withqs hai-create --ha-group=<group> --parent-port=<port> --ip-address=<ip>. A cluster heartbeat must be configured between the systems that manage the pool before an HA VIF can be created; see Setup Guide for Clustered HA Storage Pools and Storage Pool HA Failover Interface Create. - Site cluster virtual interfaces (
:sv) float between the appliances of a site so that a service address stays available. See High-availability VIF Management. - The grid management virtual interface (
:gm) is the single floating address a storage grid is managed through. There is exactly one per site cluster, and iSCSI and NVMe-oF are permanently disabled on it.
These are all managed from the High-availability VIF Management main tab, and by the cluster software rather than by the network port configuration -- that page covers use cases, failover, deliberate moves and location constraints. That is why the Modify Network Port dialog locks their Config Type to static, disables the addressing fields, and refuses IP, MTU and bond mode changes -- and why static routes cannot be created on them. Change a floating address through the HA or site VIF dialogs, not through Modify Network Port.
QuantaStor also enables ARP filtering automatically once a bonded or virtual port exists, because several addresses on the same network answering for each other's ARP requests otherwise sends traffic to the wrong interface.
Renaming a network port

Predictable kernel names such as enp3s0f1 say where the adapter is but nothing about what it does. Renaming a port gives it a name that survives hardware changes and reads clearly in the port list.
Enter the new name in New Name; the Port Information fieldset below shows the selected port's UUID, IP address, MAC address and state so you can confirm you have the right one. QuantaStor writes a systemd link file at /etc/systemd/network/10-<newname>.link that matches the port by MAC address, renames the running interface, and rewrites the port's stanza in /etc/network/interfaces.
The dialog's own guidance is worth following: prefix your management port with mgmt, and avoid the eth prefix, which collides with the names kernel drivers hand out. Interfaces are conventionally numbered from zero, as in eno0, eno1. Keep the name under 15 characters -- see Port types and naming. The name is lowercased for you.
A port cannot be renamed while it is a bond slave, while it has VLAN or virtual interface children, or while the system is using legacy ethN naming mode. Remove the bond or the children first, or switch back to predictable naming in Modify Storage System. A reboot may be needed for the rename to take effect everywhere, and QuantaStor raises an alert saying so.
The CLI equivalent is qs np-rename --port=<port> --name=<newname>.
Online, offline, restart and rescan
Four state operations sit alongside the configuration dialogs:
| Operation | Where | What it does |
|---|---|---|
| Online | Network Port toolbar; right-click → Online Network Port... | Brings the port up. The CLI equivalent is qs np-enable --port=<port>.
|
| Offline | Network Port toolbar; right-click → Offline Network Port... | Takes the port down without discarding its configuration, so Online brings it back as it was. Static routes on the port go down with it and come back when it is brought back up. The CLI equivalent is qs np-disable --port=<port>.
|
| Restart Network Port... | Right-click only | Cycles the port so a changed setting takes effect. The CLI equivalent is qs np-restart --port=<port>.
|
| Rescan All | Network Port toolbar; right-click → Rescan All Network Ports... | Discovers newly added ports and picks up configuration made outside QuantaStor. The CLI equivalent is qs np-rescan.
|
Offlining a port that has virtual interfaces attached takes the virtual interfaces down with it. Setting Config Type to disabled in Modify Network Port is not the same thing as taking the port offline: offline is temporary, whereas disabled removes the configuration and does not survive a reboot.
Ports QuantaStor discovers but that you do not want cluttering the list can be hidden with qs np-hide --port=<port> --hide=true.
QuantaStor also repairs drift on its own. Discovery re-applies the recorded MTU, subnet mask and gateway when the live configuration diverges from the configuration file, at most once every six hours per correction, and marks the port with a warning telling you to use the modify operation rather than editing the system configuration directly.
Static route management
A static route customizes traffic flow so that a specific network is reached through a gateway other than the default. This is how you reach a network that the default gateway cannot route to, whether that is across a VLAN, through a VPN tunnel, or over a dedicated replication link. Each route has two parts: the gateway on the local network through which the remote network is reachable, and the address and mask of the remote network itself.
QuantaStor's static routes are per port, which gives granular control over which interface carries traffic for which network.
Creating a static route

The dialog is also reachable by right-clicking inside the Network Static Routes tab.
| Field | Description |
|---|---|
| Storage System | The system to add the route to. |
| Parent Port | The port the route is bound to. Floating cluster interfaces are filtered out -- routes cannot be created on them. |
| Gateway IP Address | The gateway on the port's own network through which the destination network is reached. |
| Destination IP Address | The network to route to, in bind address form. QuantaStor checks the address against the mask and rejects anything that is not a network address, telling you the correct form to use. |
| Destination Subnet Mask | The mask of the destination network. |
For example, on a system whose ens192 port is 10.0.8.70/24 and which has a gateway at 10.0.8.1 that can reach the 192.168.0.0/16 network, enter a Gateway IP Address of 10.0.8.1, a Destination IP Address of 192.168.0.0 and a Destination Subnet Mask of 255.255.0.0. All traffic from that port destined for 192.168.0.0/16 is then sent via 10.0.8.1. Note that the gateway has to be on the port's own network -- QuantaStor applies the route immediately and refuses a gateway the port cannot reach.
Routes are activated the moment they are created, and QuantaStor refuses a gateway it cannot reach rather than recording a route that will never work. A duplicate destination network and mask on the same system is also refused.

Route management is integrated with the platform rather than bolted on. Each route is written to an executable script at /etc/network/<port>.staticroutes, and QuantaStor installs hooks in /etc/network/if-up.d and /etc/network/if-down.d that run it. The routes therefore enable and disable correctly when a port is brought up or down with ifup and ifdown from an SSH session, not just from the web interface. QuantaStor treats those scripts as the source of truth and imports routes it finds in them, so a route added by hand is picked up rather than overwritten. We recommend using the qs CLI or the web management interface all the same, so the routes are recorded as objects you can see in the Network Static Routes tab.
The CLI equivalent is qs sr-create --port=<port> --destination-ip-address=<network> --destination-netmask=<mask> --gateway-ip-address=<gateway>:
qs sr-create --port=ens192 --destination-ip-address=192.168.0.0 \
--destination-netmask=255.255.0.0 --gateway-ip-address=10.0.8.1
qs sr-list
Deleting a static route
Select the Network Static Routes tab in the centre of the screen, right-click the route, and choose Delete Static Route.... Alternatively, expand the port in the Storage Systems section on the left, then right-click the route.
Routes can be created and deleted at any time. Deleting one withdraws it immediately. If a port is disabled or taken offline, the routes associated with it are disabled with it.
The CLI equivalent is qs sr-delete --route-id=<uuid>, where the UUID comes from qs sr-list.
Choosing which ports carry which traffic
QuantaStor works with all major 10/25/40/56/100GbE network interface cards (NICs) from Intel, Mellanox/NVIDIA, Broadcom, Cisco, Dell, HPE and Supermicro. Most systems have a mix of speeds, and the configuration that matters is which port carries which kind of traffic.
Clear iSCSI Portal and NVMeoF Portal on the slower 1GbE ports. That stops initiators from discovering and logging in through them, and reserves those ports for management traffic. A 1GbE port that answers an iSCSI discovery is a port some client will eventually run its I/O over.
Put the 1GbE management ports on a separate network from the ports serving NAS and SAN traffic. If management and storage share a network, the system can choose the 1GbE path for storage traffic and the resulting performance problem is hard to see from either end.
Configure the gateway on the management port only. Use the Firewall tab to block the protocols each port is not meant to serve, and Network Port Usage to see which TCP and UDP ports each service uses.
Verifying connectivity
The Network Check report tests reachability from each of the system's ports, including whether jumbo frames get through end to end, and reports the round-trip time for each destination. Run it after changing an MTU, since an MTU mismatch is exactly the kind of fault that leaves a port looking healthy while large transfers stall. See Network Check View.
The CLI equivalent is qs net-check:
qs net-check
Command line reference
Every operation on this page has a CLI equivalent. Add --verbose to any command to see its full argument list.
| Command | Purpose |
|---|---|
qs np-list / qs np-get |
List all ports, or show one in detail. |
qs np-modify |
Change addressing, MTU, portal flags, autotuning, lossless networking and the per-port firewall. |
qs np-enable / qs np-disable |
Bring a port online or offline. |
qs np-restart / qs np-rescan |
Restart one port, or rediscover all ports. |
qs np-rename / qs np-hide |
Rename a port, or hide it from the interface. |
qs bond-create / qs bond-delete |
Create and delete bonded ports. |
qs vlan-create / qs vlan-delete |
Create and delete VLAN interfaces. |
qs vif-create / qs vif-delete |
Create and delete virtual interfaces. |
qs sr-create / qs sr-delete / qs sr-list / qs sr-get |
Manage static routes. |
qs hai-create / qs svr-create |
Create HA pool and site cluster virtual interfaces. |
qs net-check |
Run the network reachability and jumbo frame report. |
Note that the --port-type argument of qs np-modify documents only static and dhcp. To remove a port's configuration entirely, use the Config Type setting of disabled in the web interface.
Related pages
- Storage System -- the DNS, NTP and network settings on the Storage System Modify dialog
- Network Port Usage -- every TCP and UDP port QuantaStor and its supporting services use
- Firewall Management -- system-level firewall settings, which the per-port settings inherit from
- Storage System -- the storage system object these ports belong to
- Storage Pools -- pools whose HA failover groups own the floating virtual interfaces
- Network Shares -- NAS shares served over the ports configured here
- Storage Volumes -- SAN volumes served over the iSCSI and NVMe-oF portals configured here
- Setup Guide for Clustered HA Storage Pools -- cluster heartbeat and HA virtual interface setup
- Network Check View -- the network reachability report
- QuantaStor CLI Command Reference -- full argument lists for every command named on this page
Verified against QuantaStor 6.9.0.