• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Inexpensive managed 8-port switch?

Carson Dyle

Diamond Member
I'd like to try using link aggregation between my main desktop PC and my home file server, each of which have two ethernet ports.

What's the cheapest 8-port switch that could easily do this?
 
It doesn't? I thought that was the whole point of teaming.

Teaming requires at least 1 stream per link so you would need to be move 2 copies of something to max the link.

The exception is true multipath IO for things like iSCSI where the array and server can stagger transactions over all the links.
 
It doesn't? I thought that was the whole point of teaming.

Nope. Link aggregation allows the balancing of connections between hosts based on a hash of source and destination MAC addresses, IPs, or both.

So, basically, if you had two gigabit connections between a server and a switch, you could have two connections simultaneously at one gigabit, but any one single connection would never go above the speed of one member link.

MAC A connects to server MAC C over link 1, and MAC B connects to server MAC C over link 2. Both links are gigabit, so both clients can transfer at gigabit speeds. However, MAC A will only ever communicate over link 1, regardless of whether or not anything is communication over link 2.

Link aggregation serves a purpose, but it does not yield "double observed bandwidth." It yields "double aggregate bandwidth." (or more...double is just the example here)
 
The exception is true multipath IO for things like iSCSI where the array and server can stagger transactions over all the links.

Right, and those links are typically individual, diverse links over separate hardware for redundancy purposes...not aggregated links. Although I suppose you could use aggregation.
 
So, basically, if you had two gigabit connections between a server and a switch, you could have two connections simultaneously at one gigabit, but any one single connection would never go above the speed of one member link.

I would think it's not limited to two, even with just two NICs on the server. Those connections could be coming from more than two systems. (Or perhaps that was meant only as an example.)
 
I would think it's not limited to two, even with just two NICs on the server. Those connections could be coming from more than two systems. (Or perhaps that was meant only as an example.)

Exactly, like he said:

(or more...double is just the example here)

Many of the Cisco switches do 8 out of the box.
 
I guess I thought that when you set up two gigabit ports on a host for teaming, that the network stack round-robined the packets over the connections.
 
Right, and those links are typically individual, diverse links over separate hardware for redundancy purposes...not aggregated links. Although I suppose you could use aggregation.

Just to clarify, multipath i/o can use more than one line in a way that is "like" aggregation. I have had hosts with 2 or 4 1 gig links that where 2 or 4 distinct links (IE all 2/4 where in separate IP ranges / collision domains etc) pulling more in and out of the SAN than typical aggregation rules allow. In multipath you dispatch commands over all the links which typically will land at the SAN which has multiple interfaces itself. This allows well above 1gig for a single sequential over multiple links. I tested it to one of my smaller disk groups as 1 host with 2x 1gig pulling 210MB/s sequential doing only one transfer. Considering theoretical is 250MB/s, I considered that fine. What was happening is the host would dispatch say 25 requests for sectors on one link and then 25 on the next allowing the SAN to service the next 25, and get them going over the wire before the first 25 had completed.
 
I guess I thought that when you set up two gigabit ports on a host for teaming, that the network stack round-robined the packets over the connections.

You can do this if both hosts support round-robin load balancing and you won't ever have more than two hosts connected together. However, if the hosts are connected to a larger network, a round-robin LAG can cause packets to arrive out of order. If the network is really busy, this can result in major performance degradation.
 
Just to clarify, multipath i/o can use more than one line in a way that is "like" aggregation. I have had hosts with 2 or 4 1 gig links that where 2 or 4 distinct links (IE all 2/4 where in separate IP ranges / collision domains etc) pulling more in and out of the SAN than typical aggregation rules allow. In multipath you dispatch commands over all the links which typically will land at the SAN which has multiple interfaces itself. This allows well above 1gig for a single sequential over multiple links. I tested it to one of my smaller disk groups as 1 host with 2x 1gig pulling 210MB/s sequential doing only one transfer. Considering theoretical is 250MB/s, I considered that fine. What was happening is the host would dispatch say 25 requests for sectors on one link and then 25 on the next allowing the SAN to service the next 25, and get them going over the wire before the first 25 had completed.

Oh, I understand how MPIO works. My post was stating that they don't rely on typical link aggregation protocols like LACP or PAGP. They multipath at a higher level.
 
Oh, I understand how MPIO works. My post was stating that they don't rely on typical link aggregation protocols like LACP or PAGP. They multipath at a higher level.

I figured you did but a laymen reading that back and forth might not have gotten it.
 
Back
Top