Static LAG with switch from another brand

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Static LAG with switch from another brand

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Static LAG with switch from another brand
Static LAG with switch from another brand
2019-05-06 16:37:31 - last edited 2019-05-06 18:45:55
Model: TL-SG1024DE  
Hardware Version: V3
Firmware Version: 1.0.1 Build 20180629 Rel.58591

Hello.

 

I know that this question is a stretch, but if someone could drop a hint I would be very grateful.

I have two managed switches, one is a TP-Link TL-SG1024DE, the other is an HPE Procruve J9028B (1800-24G).

 

I want to create a LAG between both but I am unsure if it can work at all.

While the TL-SG1024DE has the simple Static LAG setting page, the Procurve has other naming schemes that might mean the same thing or not, for example:

- Trunk Membership (Aggregation);

- LACP Setup;

 

The TL-SG1024DE switch doesn't seem to have any LACP settings, so that seems to be a dead end, but the Trunk Membership - is it possible that it achieves the same funcionality as Static LAG?

 

On the TP-Link I've created a Static LAG (LAG 1) using ports 15 and 17, then on the HPE Procurve I've created a Trunk Membership (Trunk T1) (Aggregation Mode: SMAC XOR DMAC) using ports 16 and 18; port 15<->16 and port 17<->18. Thei idea is essentially to create a 2Gbps uplink instead of a single 1Gbps uplink, I'm considering expanding it to at least 4Gbps if this works, but how can I be sure it is working?

 

I don't see any critical issues that should happen when there's a loop, but I also am not sure if I have the 2Gbps uplink between both switches using this configuration.

 

Aditionally, this is some of the statistics that I could gather from both switches, with a few seconds of delay (~5) between the HPE switch/ports and the statistics in the TP-Link ones:

 

Port 15 (TPL - LAG 1)
- TxGoodPkt: 2232
- TxBadPkt: 0
- RxGoodPkt: 336566
- RxBadPkt: 0


Port 16 (HPE - Trunk 1)

- Received Packets: 3163

- Received Errors: 0

- Transmitted Packets: 410757

- Transmitted Errors: 0


 

Port 17 (TPL - LAG 1)
- TxGoodPkt: 761773
- TxBadPkt: 0
- RxGoodPkt: 93328
- RxBadPkt: 0

 

Port 18 (HPE - Trunk 1)

- Received Packets: 951143
- Received Errors: 0
- Transmitted Packets: 116757

- Transmitted Errors: 0

 

 

 

 

Thanks for your comments.

  0      
  0      
#1
Options
5 Reply
Re:Static LAG with switch from another brand
2019-05-08 11:09:15

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.

  1  
  1  
#2
Options
Re:Re:Static LAG with switch from another brand
2019-05-08 12:01:37

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.

  0  
  0  
#3
Options
Re:Re:Re:Static LAG with switch from another brand
2019-05-09 02:01:52

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.

  1  
  1  
#4
Options
Re:Re:Re:Re:Static LAG with switch from another brand
2019-05-09 09:21:38

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.

  0  
  0  
#5
Options
Re:Re:Re:Re:Re:Static LAG with switch from another brand
2019-05-13 08:41:08

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 :)

 

  2  
  2  
#6
Options