I’d like to connect our TS833XU-RP to two seperate switches for failover in the case one switch becomes offline.
In a test scenario I created an active/backup trunk, but several questions popped up:
is is possible to remove the network adapter, from which the trunk got it’s MAC address - is it possible to change the MAC address of the trunk or must I delete the whole trunk? (If I hover the deselect button, the following message appears: “You can not deselect the adapter. The MAC address of the adpater is currently used by the port trunking port.”)
How can I select a “primary” interface for a trunk, which gets the active interface after recovery? (In the test setup the last active interface stayed active)
Can I create an active/backup trunk over two LACP trunks?
A trunk is not really meant to be used between two different switches. You would be better off just using two separate network connections and letting the QNAP decide which connection is fastest/optimal. Trunking is really meant to allow you to combine multiple ports to increase the speed of the connection - so two 1 Gbit ports to give you a 2 Gbit connection, two 2.5 Gbit ports gives you 5 Gb, etc. Yes, you can set things up to give you fallover capability, etc. but that’s not really designed to be done across two switches. I’ve not really seen that.
So to attempt to answer your questions - I don’t think you can change the MAC address of the trunk. Why do you want to do that?
For question 2, I don’t think you get a choice over which is primary and which is secondary. That’s all handled by the protocol.
For question 3, I have never seen any ability to do trunks of trunks. Doesn’t make sense. A trunk is already an encapsulated tunnel where the traffic is split between both connections.What would be the purpose of creating a “trunk of a trunk”? The trunk already has redundancy built into it. I’ll have to try adding a trunk port to another trunk on one of my Ciscos…
Hello NA9D,
thanks for your relpy.
IMHO an active/passive trunk is designed to enable the passive port when the switch on the active port fails (or reboots during firmware uograde). In that case, it’s best not to connect the passive port to the same switch.
To clarify my questions a little bit:
For question 1: If I create an active/passive trunk over an 1 Gbit and 10 Gbit Interface and later spend some money for extra 10Gbit interfaces, I would tend to remove the 1 Gbit interface from the trunk so that the failover connection definitely runs on the 10 Gbit interface.
For question 2: Yes, seems on a QNAP ist’s handled by the protocol. (Or I overlooked the relevant settings). On Linux it’s no problem to set a primary interface of an active/passive bond… This has the advantage that I specify which network switch handles the “normal” traffic.
For question 3: IMO trunk of trunks has the advantage to create (two) (LACP) trunks for bandwidth aggregation, connect each to a seperate (ToR-) switch and then trunk them in an active/passive trunk for high(er) availability. (We use this configuration on several Linux hosts and also on our NetApp.)
Network switches (like your Ciscos) use STP or SPB to handle redundancy of inter switch connections.
Seems like it would be easier in your case to simply have a 10 Gbit connection and a 1 Gbit backup connection. Don’t bother trunking. Just have two connections and two IPs. I suppose a trunk would make things simpler as you could have a single IP.
I don’t know if QNAP supports the type of trunk you are looking to do…
Hi guys! New here and to QNAP switching, but not switching. In the QNAP world is a “trunk” a LAG/LACP? Combining two or more ports to act as one. I’ve always known trunks as a way to pass all VLANs over a port.
I’m here looking for a way to do trunks (all VLANs over a port) on the QSW-M3216R-8S8T and read this post. Sorry to hijack, just trying to get with the QNAP lingo.
Yeah, I get the confusion. In the Cisco lingo, a trunk port is a port that has multiple VLANs encapsulated on a single port. A port-channel is a LAG. In QNAP world, trunks are LAGs.
I’m not entirely sure what you are trying to do here and why you want to send multiple VLANs to the QNAP. You’d probably be better off doing VLAN routing.
You may be able to set up some trunk ports using the Virtual Switch function of the QNAP but I am not sure on that.
The QSW will be connected to (4) HPE e920 blades in an EL8000. Each of the blades will be running Oracle Linux with K8s and VMs. Segmenting into VLANs for certain workloads. So the four “hosts” will need to see all VLANs over the uplinks for North/South traffic.
Hold on - Are you talking QNAP NAS or QNAP Switch here.
If you are talking a QNAP Switch, then you should probably start a new thread. I don’t have any knowledge of what QNAP switches can do. I would imagine they do trunks.
Question: 2 How can I select a “primary” interface for a trunk, which gets the active interface after recovery? (In the test setup the last active interface stayed active) Answer:
I am happy to inform you that, our development team has completed the verification. It’s possible to set primary interface.
But only the modes active_back, balance-tlb, and balance-alb allow manual specification of the primary interface.
I’d like to trunk two interfaces (eth0 and eth1) for bandwidth aggregation in one LACP channel (bond0) to switch1
and two other interfaces (eth2 and eth3) in a second trunk (bond1) to switch2
(both switches are “standalone” - no stack no MLAG etc.)
Now I’d like to add bond0 and bond1 to an active/passive trunk bond2 for redundancy , so if switch1 gets offline, bond2 sets bond1 as active port
Thank you for the detailed explanation and the diagram—it’s very helpful in understanding your intended configuration.
We’ve reviewed this setup with our technical team, and unfortunately, the configuration you’re aiming for—nesting bonded interfaces (i.e., combining bond0 and bond1 into a higher-level bond2)—is not supported. This is due to a limitation in the Linux bonding driver, which does not allow bonding within another bond (nested bonding). As a result, our QNAP system also does not support this configuration.
We understand your goal of achieving high availability and minimizing service outages, and we truly appreciate your effort in designing a resilient network architecture. While nested bonding isn’t possible.
At QNAP, we are continuously working to enhance our products and deliver features that meet customer expectations. We will share your suggestion with our development team for evaluation. After a thorough feasibility study, they will consider it for potential inclusion in future updates.
We truly appreciate your input—it helps us improve and better serve your needs.
