<
Switches
TL-SG108E Link Aggregation (LAG) Type Information
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
TL-SG108E Link Aggregation (LAG) Type Information
Posts: 2
Helpful: 1
Solutions: 0
Stories: 0
Registered: 2018-01-06
2018-01-07 01:18:10
Posts: 2
Helpful: 1
Solutions: 0
Stories: 0
Registered: 2018-01-06
TL-SG108E Link Aggregation (LAG) Type Information
2018-01-07 01:18:10
Tags:
I'm wondering what type of LAG support the TL-SG108E has. The spec sheet / product data sheet only sets "Link Aggregation" without specifying further.
I read in ol this post that only static link aggregation is supported (ergo, no LACP):
http://forum.tp-link.com/showthread.php?98410-W2016-Teaming-in-LACP
But this post from a year ago states only 2 link aggregation groups can be handled per switch, yet that also says that applies to the V2.0 hardware:
http://forum.tp-link.com/showthread.php?94246-How-to-setup-LAG-between-a-couple-of-TL-SG108E-switches
Is this still accurate? Or has this changed with newer firmware? Is this also the case with the V3.0 hardware, or can I have 3 LAGs on one switch? (One incoming from another TL-SG108E, one outgoing to another TL-SG108E, and one for a server)
Are there any known OS or hardware incompatibilities / issues with it, aside from OSs that only support LACP? I plan to buy a new dual NIC for my home lab server and went to confirm compatibility before I buy. (I'm looking at the Rosewill RNG-407-Dualv2 if that's relevant, but I may link other hardware in the future via a LAG.)
Finally, is the link aggregation IEEE 802.1AX / 802.3ad compliant? I'd assume so, but I just want to confirm it isn't a proprietary implementation.
I read in ol this post that only static link aggregation is supported (ergo, no LACP):
http://forum.tp-link.com/showthread.php?98410-W2016-Teaming-in-LACP
But this post from a year ago states only 2 link aggregation groups can be handled per switch, yet that also says that applies to the V2.0 hardware:
http://forum.tp-link.com/showthread.php?94246-How-to-setup-LAG-between-a-couple-of-TL-SG108E-switches
Is this still accurate? Or has this changed with newer firmware? Is this also the case with the V3.0 hardware, or can I have 3 LAGs on one switch? (One incoming from another TL-SG108E, one outgoing to another TL-SG108E, and one for a server)
Are there any known OS or hardware incompatibilities / issues with it, aside from OSs that only support LACP? I plan to buy a new dual NIC for my home lab server and went to confirm compatibility before I buy. (I'm looking at the Rosewill RNG-407-Dualv2 if that's relevant, but I may link other hardware in the future via a LAG.)
Finally, is the link aggregation IEEE 802.1AX / 802.3ad compliant? I'd assume so, but I just want to confirm it isn't a proprietary implementation.
#1
Options
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Thread Manage
Announcement Manage
3 Reply
Posts: 4334
Helpful: 1039
Solutions: 173
Stories: 3
Registered: 2015-12-05
Re:TL-SG108E Link Aggregation (LAG) Type Information
2018-01-07 17:45:33
rjcuthbertson wrote
I'm wondering what type of LAG support the TL-SG108E has.
It supports static LAG only, not LACP.
But this post from a year ago states only 2 link aggregation groups can be handled per switch, yet that also says that applies to the V2.0 hardware:
Is this still accurate? Or has this changed with newer firmware? Is this also the case with the V3.0 hardware, or can I have 3 LAGs on one switch?
Latest firmware for HW V2 is 1.0.0 Build 20170717 Rel.42042(Beta) and for HW V3 it's 1.0.0 Build 20160722 Rel.50167. It still handles only two static LAG groups. The TL-SG108E is an entry-level aka "easy smart" switch. If you need LACP or more LAG groups, take a look at the TL-SG2008 smart switch, which handles up to 6 LAG groups.
Are there any known OS or hardware incompatibilities / issues with it, aside from OSs that only support LACP?
If the OS supports only LACP, it won't work with static LAG. If the OS supports static LAG, it needs to support the same hash algorithm as the switch.
Finally, is the link aggregation IEEE 802.1AX / 802.3ad compliant? I'd assume so, but I just want to confirm it isn't a proprietary implementation.
802.1AX and 802.1aq are the vendor-independent standards for LACP, so no, the TL-SG108 doesn't support those standards. 802.3ad is QinQ (aka Stacked VLANs) and has nothing to do with LACP. Before the year 2008, LACP was defined in 802. 1ad, but not 802. 3ad.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#2
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 2
Helpful: 1
Solutions: 0
Stories: 0
Registered: 2018-01-06
Re:TL-SG108E Link Aggregation (LAG) Type Information
2018-01-07 21:12:43
Thanks for your reply. You've at least clarified the 2 LAG restriction for me. And I appreciate the suggested alternative device. I can make it work for now with only 2 LAGs per device, I just need to wire my home lab server as the farthest terminal point of the network rather than having it be somewhere in the middle. But I have to tell you, I don't trust the validity of your answer regarding whether this static LAG implementation is standards compliant or not to be credible, as your last few points regarding the IEEE standards are a bit misguided. You may or may not be correct, but if you are correct, it wouldn't be because you understood the concept thoroughly enough to provide an accurate answer - though I absolutely do not blame you in the slightest. That whole situation is pretty confusing until you understand the history of it. It took me many hours of reading about link aggregation to really get my head around the IEEE standards, the broad array of vocabulary used meaning the same things, as well as the vocabulary used incorrectly, and the various forms of link aggregation that exist. I'm still pretty green at networking, but as I've identified it as a weak area in my IT tool belt it's my goal to really work on those skills this year, so I've been taking a deep dive in every concept I come across.
You made 4 statement in regard to this final question, which I'll address point by point:
1) IEEE 802.1AX and 802.1aq are the vendor independent standards for LACP
2) The TL-SG108E doesn't support IEEE 802.1AX, nor 802.1aq
3) 802.3ad is QinQ, and has nothing to do with LACP.
4) LACP was originally defined in 802.1ad not 802.3ad.
[HR][/HR]
1)
802.1AX is the standard for Link Aggregation. A section of this includes the standard for LACP, but that is only one part of 802.1AX. The best article I've found about this topic that clearly describes link aggregation at large, as well as the relevant IEEE standards is: https://datacenteroverlords.com/2013/09/02/link-aggregation/ A relevant quote from that article to this particular point of confusion would be:
802.1aq is Shortest Path Bridging. I don't see how it relates to link aggregation. https://en.wikipedia.org/wiki/IEEE_802.1aq
[HR][/HR]
2)
I'm assuming your answer here that the TL-SG108E's Link Aggregation implementation isn't compliant with the 802.1AX spec (which it most likely is, but not assuredly is), as opposed to being a proprietary implementation comes from your preconception that 802.1AX is one and the same as LACP, which it is not. Since the logical basis is flawed, the conclusion is as well. Do you know that it isn't 802.1AX compliant, or was that based on the invalid assumption?
[HR][/HR]
3)
802.3ad doesn't have anything to do with LACP anymore. You are correct about that. However, Q-in-Q is 802.1ad so 802.3ad has nothing to do with Q-in-Q either. Additionally, my use of the reference to 802.3ad was as such: "802.1AX / 802.3ad". I wrote it this way to denote that as it was previously listed under 802.3ad prior to its move in 2008, you will find both being used to reference the same thing, especially the closer the date of the article or discussion is to 2008 or earlier. And finally, regarding .3ad vs .1ad, we come to...
[HR][/HR]
4)
The entire reason the protocol was moved from one standard to another was because, prior to 2008, it was indeed included in 802.3ad standard. But because 802.3 manages the Physical Layer of the OSI model (Ethernet), this was an inappropriate location for Link Aggregation to be described, hence its move to the 802.1 Higher Layer LAN Protocols. From the Wikipedia article on Link Aggregation:
https://en.wikipedia.org/wiki/Link_aggregation#Move_to_802.1_layer_in_2008
[HR][/HR]
That being said, thanks again for trying to help. I hope you've learned something today too :)
You made 4 statement in regard to this final question, which I'll address point by point:
1) IEEE 802.1AX and 802.1aq are the vendor independent standards for LACP
2) The TL-SG108E doesn't support IEEE 802.1AX, nor 802.1aq
3) 802.3ad is QinQ, and has nothing to do with LACP.
4) LACP was originally defined in 802.1ad not 802.3ad.
[HR][/HR]
1)
IEEE 802.1AX and 802.1aq are the vendor independent standards for LACP
802.1AX is the standard for Link Aggregation. A section of this includes the standard for LACP, but that is only one part of 802.1AX. The best article I've found about this topic that clearly describes link aggregation at large, as well as the relevant IEEE standards is: https://datacenteroverlords.com/2013/09/02/link-aggregation/ A relevant quote from that article to this particular point of confusion would be:
What about LACP? LACP is part of the 802.1AX standard, but it is neither the entirety of the 802.1AX standard, nor is it required in order to stand up a LAG. LACP is also not link aggregation. It is a protocol to build LAGs automatically, versus static. You can usually build an 802.1AX LAG without using LACP.
802.1aq is Shortest Path Bridging. I don't see how it relates to link aggregation. https://en.wikipedia.org/wiki/IEEE_802.1aq
[HR][/HR]
2)
The TL-SG108E doesn't support IEEE 802.1AX, nor 802.1aq
I'm assuming your answer here that the TL-SG108E's Link Aggregation implementation isn't compliant with the 802.1AX spec (which it most likely is, but not assuredly is), as opposed to being a proprietary implementation comes from your preconception that 802.1AX is one and the same as LACP, which it is not. Since the logical basis is flawed, the conclusion is as well. Do you know that it isn't 802.1AX compliant, or was that based on the invalid assumption?
[HR][/HR]
3)
802.3ad is QinQ (aka Stacked VLANs) and has nothing to do with LACP.
802.3ad doesn't have anything to do with LACP anymore. You are correct about that. However, Q-in-Q is 802.1ad so 802.3ad has nothing to do with Q-in-Q either. Additionally, my use of the reference to 802.3ad was as such: "802.1AX / 802.3ad". I wrote it this way to denote that as it was previously listed under 802.3ad prior to its move in 2008, you will find both being used to reference the same thing, especially the closer the date of the article or discussion is to 2008 or earlier. And finally, regarding .3ad vs .1ad, we come to...
[HR][/HR]
4)
Before the year 2008, LACP was defined in 802. 1ad, but not 802.3ad.
The entire reason the protocol was moved from one standard to another was because, prior to 2008, it was indeed included in 802.3ad standard. But because 802.3 manages the Physical Layer of the OSI model (Ethernet), this was an inappropriate location for Link Aggregation to be described, hence its move to the 802.1 Higher Layer LAN Protocols. From the Wikipedia article on Link Aggregation:
Move to 802.1 layer in 2008 - David Law noted in 2006 that certain 802.1 layers (such as 802.1X security) were positioned in the protocol stack below Link Aggregation which was defined as an 802.3 sublayer. This discrepancy was resolved with formal transfer of the protocol to the 802.1 group with the publication of IEEE 802.1AX-2008 on 3 November 2008.[SUP]
[/SUP]
https://en.wikipedia.org/wiki/Link_aggregation#Move_to_802.1_layer_in_2008
[HR][/HR]
That being said, thanks again for trying to help. I hope you've learned something today too :)
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#3
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 4334
Helpful: 1039
Solutions: 173
Stories: 3
Registered: 2015-12-05
Re:TL-SG108E Link Aggregation (LAG) Type Information
2018-01-07 22:08:08
Yes, sorry, I did confuse 802.1ad and 802.3ad. Link aggregation was formerly defined in clause 43 of the 802.3 standard added by the IEEE 802.3ad task force.
It has since then been transferred to layer 802.1 in the year 2008. See https://en.wikipedia.org/wiki/Link_aggregation:
In short: if you need LACP, which is vendor-independent, take a look at TL-SG2008. This switch supports vendor-independent LACP and in addition it supports proprietary static LAG with two different hash algorithms. According to its specifications, its LAG functions do comply to (quote) "802.3ad", which should actually be 802.1AX.
If you need to use TL-SG108E, there is no LACP, but only static LAG. Furthermore, you can't change its hash algorithm, which isn't even documented somewhere (at least I couldn't find anything about which one is implemented). According to its specifications, it does not comply to 802.1AX.
I have both switches here in my office. If you ask me, I will not buy an Easy Smart switch anymore, but only smart switches, given the trouble I had and the time spent to set up a network with the TL-SG108E / TL-SG108PE Easy Smart switches.
It has since then been transferred to layer 802.1 in the year 2008. See https://en.wikipedia.org/wiki/Link_aggregation:
These umbrella terms encompass not only vendor-independent standards such as Link Aggregation Control Protocol (LACP) for Ethernet defined in IEEE 802.1AX and IEEE 802.1aq or the previous IEEE 802.3ad, but also various proprietary solutions.
In short: if you need LACP, which is vendor-independent, take a look at TL-SG2008. This switch supports vendor-independent LACP and in addition it supports proprietary static LAG with two different hash algorithms. According to its specifications, its LAG functions do comply to (quote) "802.3ad", which should actually be 802.1AX.
If you need to use TL-SG108E, there is no LACP, but only static LAG. Furthermore, you can't change its hash algorithm, which isn't even documented somewhere (at least I couldn't find anything about which one is implemented). According to its specifications, it does not comply to 802.1AX.
I have both switches here in my office. If you ask me, I will not buy an Easy Smart switch anymore, but only smart switches, given the trouble I had and the time spent to set up a network with the TL-SG108E / TL-SG108PE Easy Smart switches.
༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
0
We appreciate your feedback. Feel free to let us know more. Log in to submit feedback.
#4
Options
- Copy Link
- Report Inappropriate Content
Thread Manage
Announcement Manage
Posts: 2
Helpful: 1
Solutions: 0
Stories: 0
Registered: 2018-01-06
2018-01-07 01:18:10
Posts: 2
Helpful: 1
Solutions: 0
Stories: 0
Registered: 2018-01-06
Information
Helpful: 1
Views: 31644
Replies: 3
Voters 0
No one has voted for it yet.
Tags
Related Articles
Report Inappropriate Content
Transfer Module
New message