It will definitely not work with LACP. You are doing fine, I think. Trunk is an old name of link aggregation came from cisco firstly, then trunk became "tagged link", but it is OK, that some vendors still use Trunk as Link Aggregation/Etherchannel. If it didn't work, you would receive loop. I would enable loopback-detection on your LAG group (on HP, as it is smarter, than easysmart), so I would see, if LAG doesn't work.

Mitya wrote

It will definitely not work with LACP. You are doing fine, I think. Trunk is an old name of link aggregation came from cisco firstly, then trunk became "tagged link", but it is OK, that some vendors still use Trunk as Link Aggregation/Etherchannel. If it didn't work, you would receive loop. I would enable loopback-detection on your LAG group (on HP, as it is smarter, than easysmart), so I would see, if LAG doesn't work.

Thanks for your reply.

I suppose you might be right, but I was just wondering if there is a practical way to test if the 2Gbps uplink is actually working.

I imagine that in theory it could be tested using 4 1Gbps devices, two on each switch, sending packets to the other two on the second switch and monitoring the speeds with and without this LAG, not sure if you have any other suggestion for that.

As for your loopback-detection advice, it's good advice, but unfortunately the HP 1800-24G does not have any loopback protection, at least I've looked through the GUI and the user manual, nothing of the sort. The TP-Link however, it does have loopback detection, which according to the definition blocks the port responsible for the looping connection, I'm not sure if I can use it to test that because I assume it just does its thing without logging anything, so in practice it might be difficult to use that for LAG testing purposes.

Thanks again.

lmp wrote

Mitya wrote

It will definitely not work with LACP. You are doing fine, I think. Trunk is an old name of link aggregation came from cisco firstly, then trunk became "tagged link", but it is OK, that some vendors still use Trunk as Link Aggregation/Etherchannel. If it didn't work, you would receive loop. I would enable loopback-detection on your LAG group (on HP, as it is smarter, than easysmart), so I would see, if LAG doesn't work.

 

Thanks for your reply.

I suppose you might be right, but I was just wondering if there is a practical way to test if the 2Gbps uplink is actually working.

I imagine that in theory it could be tested using 4 1Gbps devices, two on each switch, sending packets to the other two on the second switch and monitoring the speeds with and without this LAG, not sure if you have any other suggestion for that.

 

As for your loopback-detection advice, it's good advice, but unfortunately the HP 1800-24G does not have any loopback protection, at least I've looked through the GUI and the user manual, nothing of the sort. The TP-Link however, it does have loopback detection, which according to the definition blocks the port responsible for the looping connection, I'm not sure if I can use it to test that because I assume it just does its thing without logging anything, so in practice it might be difficult to use that for LAG testing purposes.

 

Thanks again.

Hi Imp

If you want to confirm the bandwidth of LAG, as you said, you need 4 1Gbps devices and run the speed testing like iperf at the same time. If two groups of devices can get the 1 Gbps speed at the same time, then it means that LAG has 2 Gbps bandwidth.

This is related to the load balancing of LAG, still need to consider the has algorithm(Source MAC/ Source IP......). When you use 4 devices, you can choose SRC MAC + DST MAC.

Andone wrote  

Hi Imp

If you want to confirm the bandwidth of LAG, as you said, you need 4 1Gbps devices and run the speed testing like iperf at the same time. If two groups of devices can get the 1 Gbps speed at the same time, then it means that LAG has 2 Gbps bandwidth.

This is related to the load balancing of LAG, still need to consider the has algorithm(Source MAC/ Source IP......). When you use 4 devices, you can choose SRC MAC + DST MAC.

Hi Andone.

Sorry, but I didn't quite understand that last bit:

"This is related to the load balancing of LAG, still need to consider the has algorithm(Source MAC/ Source IP......). When you use 4 devices, you can choose SRC MAC + DST MAC."

What do you mean by that precisely?

Where should I consider that algorithm? The switch itself does LAG by aggregating the ports but has no other settings whatsoever.

Or did you mean to use specific options using iPerf? Honestly, I never used iPerf so if that statement is about iPerf it would be good to know.

lmp wrote

Andone wrote  

Hi Imp

If you want to confirm the bandwidth of LAG, as you said, you need 4 1Gbps devices and run the speed testing like iperf at the same time. If two groups of devices can get the 1 Gbps speed at the same time, then it means that LAG has 2 Gbps bandwidth.

This is related to the load balancing of LAG, still need to consider the has algorithm(Source MAC/ Source IP......). When you use 4 devices, you can choose SRC MAC + DST MAC.

 

Hi Andone.

Sorry, but I didn't quite understand that last bit:

"This is related to the load balancing of LAG, still need to consider the has algorithm(Source MAC/ Source IP......). When you use 4 devices, you can choose SRC MAC + DST MAC."

 

What do you mean by that precisely?

Where should I consider that algorithm? The switch itself does LAG by aggregating the ports but has no other settings whatsoever.

Or did you mean to use specific options using iPerf? Honestly, I never used iPerf so if that statement is about iPerf it would be good to know.

Andone meant this. If you check smarter switches, you would be able to configure hash algorithm for LAG, but for EasySmart it seems impossible to configure, so just ignore it. I am not sure, but default for all switches are probably DST MAC+SRC MAC. To tell the truth, I myself have never changed hash in my life :)