Talk:Link aggregation

message: What OSI layer does link aggregation occur at? —Preceding unsigned comment added by 192.91.171.36 (talk • contribs) 
:I guess it would conceptually fit between layers one and two. The data link layer (OSI layer 2) would be deciding which trunk to pass the data to. Then you'd have the aggregation layer splitting it between the ports and then the physical layer (OSI layer 1) for each port. Plugwash 21:02, 7 May 2006 (UTC)
thread_title: OSI layer

message: LACP is part of the 802.3ad specification, yet is not mentioned in this article.  Anyone care to add it in the appropriate place?  fonetikli 23:00, 20 July 2006 (UTC)
thread_title: LACP

message: Redirecting 'ethernet bonding' here would be good. 83.27.231.169 20:15, 31 August 2006 (UTC)
replies: text: Redirect was created 23:54, 13 February 2008. -—Kvng 15:22, 7 January 2013 (UTC)
thread_title: Another redirect

message: Can someone explain or give a link to a definition for path polarization?  I cannot find anything specific in a Google search.
Bezenek (talk) 19:55, 19 August 2010 (UTC)
replies: text: I have trimmed this section to remove unsupported and confusing information. -—Kvng 15:38, 7 January 2013 (UTC)
thread_title: Path Polarization Definition?

message: I'm not a networking guru, but shouldn't there be some more reference to aggregation being used for network availability & redundancy rather than just bandwidth?  I've seen it used a few times, and always for this purpose. 
Also, how does 'static' and 'dynamic' link agregation fit in? zorruno 23:56, 7 September 2006 (UTC)
replies: text: There is a mention of it, but it only protects against link failures not equipment failures. Plugwash 22:28, 14 October 2006 (UTC)
thread_title: Network Availability

message: As far as i know, after testing a current Linux Kernel. It can bond different branded Ethernet Adapters,
but they are required to atleast use the same driver base e.g. e100/e1000 [Intel], 3c59x [3Com].
This means mixing of different branded Ethernet Chipsets may not be possible in some cases.
Linux, BSD & Windows Based operating systems do allow for IP Host Based Load Balancing / Failover. 
this method does not require the use of a high end switch with Layer 2 Management or 802.1ad Support
Hard__warE: 165.228.140.189 01:27, 12 April 2007 (UTC)
thread_title:  Linux Support and IP Based Load Balancing / Failover 

message: Someone should add a limitations section or at least mention it. Remember, that Port Aggregation will only solve bandwidth issues if it is several devices hitting one device. There are at a lot of misconceptions that this solves all bandwidth issues.
Hqduong 03:58, 9 May 2007 (UTC)
replies: text: Added a paragraph of limitations 210.131.130.125 (talk) 06:51, 13 April 2008 (UTC)
thread_title: Limitations

message: The page states "originally, link aggregation was developed to provide redundancy, and not bandwidth benefits".  I don't find that in any of the cited material.  Moreover, I don't believe that it's strictly true.  Is this an inference based on the load-balancing behavior?  Did somebody assume that since a single flow tops out at the speed of a single aggregated device that this was "developed to provide redundancy" rather than "bandwidth"?
The Linux bonding.txt documentation (linked from this article) hints at the real reason starting at line 1784.  Basically, TCP (and most reordering protocols) don't handle packet reordering well.  TCP detects the out-of-order packets as lost packets (typically signifying drops due to congestion) and can generate spurious, unnecessary retransmits.  IP fragment-handling gets even more pathological (worst case, it becomes O(N) where N is the number of fragments).
I think that aggregation was originally not designed to provide redundancy but just aggregate bandwidth.  The common defaults for interval time of LACP are pretty low for timely failover.  Most aggregation systems can be configured statically without LACP as well.  Rather, it seems that they were just designed to aggregate and the port-selection algorithms grew this way because they had to (i.e. straight round-robin hurt performance so much that it was required).  All of this seems to indicate the opposite of what the article suggests, although without any original material to cite, I don't know if we should even take a position on this.
So, should we reword this bit to be a bit more neutral?--Jayson Vantuyl (talk) 14:36, 29 November 2008 (UTC)
thread_title: Packet Reordering

message: I wish there could be a little bit more info and how to calculate statistics on link and client aggregation for uplink backbones. 
For example, how to calculate how much bandwidth do I need if there are 200 possible clients, within reach of my wireless signal, to provide them with 1 Mbps speeds, in a home environment? 
I feel the need to learn this but there's nowhere to be found. Maybe it belongs to his article? Yubal (talk) 00:54, 21 April 2009 (UTC)
thread_title:  What about uplink? 

message: But in the past I've worked with port trunking and it's different from link aggregation. Port trunking assigns the same IP to all the ports on the trunk, and you need a special switch to connect to (or to go port to port between two systems) for port trunking to work as you cannot have multiple ports on a network with the same IP.
With (Linux) port aggregation the ports have different IPs and you do not need a trunking switch or any special equipment.
Now in my Linux bandwidth testing I found that aggregating two e1000 ports resulted in no increase of bandwidth, which I found surprising, but from the article text it seems that all traffic from a single session will flow down one wire. With muliple sessions the bandwidth should be more fully usable, but I did not test in that configuration. The trunking tests I did were with Solaris Sparc and I was CPU limited and unable to determine if there was a net bandwidth gain as I barely had the CPU to saturate one port. 
I guess I need to look up the specification and see what it says. But from what I know, port trunking is something different (and I don't think it really caught on). Then again, maybe I'm just confused about how things are named.
76.254.74.81 (talk) 17:46, 19 August 2009 (UTC)
thread_title:  Maybe I'm confused 

message: There is no introduction to this part at all. What is it about really and why such long part about one type of LACP implementation? Why is the Linux LACP so important to note in a general article about LACP, when not for example LACP config modes on Cisco or HP Procurve switches is mentioned?
There is also words used ("slaves") which is not defined at all.  —Preceding unsigned comment added by 212.73.30.50 (talk) 13:18, 3 March 2011 (UTC)
thread_title: Linux part, out of context?

message: SMLT is proprietary to Nortel.  Kudos to them for being the first, and for a while, only, vendor with a solution but they no longer stand alone here.  Cisco has at least three technologies (MEC - 6500 series, CrossStack EtherChannel (3750) and VPC (Nexus)as mentioned above), and even 3Com (DLA - 5500/5500G) and D-Link have (or had) offerings.
Point is, if we're going to include SMLT, we should include others.  (I vote for listing others as well.)
Titaniumlegs (talk) 23:04, 30 September 2011 (UTC)
thread_title: SMLT and other stacking/multichassis technologies

message: This article uses the acronym LAG multiple times but never spells it out. If you search for "Link Aggregate Group" using Wikipedia search, it sends you to this page, but searching for "Link Aggregation Group" returns a list of possibilities that include this page. The phrase "link aggregation group" is used on this page. According to www.acronymfinder.com the IEEE standard reference is "Link Aggregation Group." This article would be clearer if it showed what the acronym stood for.  — Preceding unsigned comment added by 108.52.128.210 (talk) 15:21, 25 July 2012 (UTC)
thread_title:  Use of acronym LAG not clear 

message: I have years of sysadmin experience and even I am put off by the way this article plunges right into the subject matter without a simple explanation of the topic.
Please start in the beginning and try to imagine what someone who does not know the subject might wonder.  For instance, I do not know if IP Bonding can be done between hosts?  In short, despite the high quality of some of the writing, an executive summary must precede the article that tells people with varying degrees of understanding whether this is the article they need to read.
RJMS (talk) 22:58, 12 November 2012 (UTC)
replies: text: The first paragraph is a little dense but not buzzword bloated and seems to describes what's happening and the motivation for it. I've seen much worse. Constructive suggestions for improvement are welcomed. -—Kvng 21:33, 14 November 2012 (UTC)
thread_title:  Earth to Experts that wrote this - COME IN PLEASE!!! 

message: The short section headed "Advantages over static configuration" is most confusing, since the word 'static' is used to differentiate types of aggregation (alternative types on HP switches being 'dynamic' and 'manual'). It seems to me that this isn't the meaning intended here?  — Preceding unsigned comment added by WestNab (talk • contribs) 17:11, 3 January 2013 (UTC)
replies: text: My reading of this is that the comparison is being made between using LACP and setting up the active ports manually (statically). When using LACP, the two switches talk to each other and negotiate which ports are active in the link aggregation group. This means one of the group of cables could be unplugged, and there would be no disruption of service, as the LACP would tell both switches to disable the port in the group.  Does that answer your confusion? —fudoreaper (talk) 13:38, 4 January 2013 (UTC)
thread_title:  Advantages over static configuration - confusing? 

message: Coped from User_talk:Kvng#Link_Aggegation
Hi,
I think you added some comments to sources used in Link aggregation and by that setting them as "missing ureliable resources".
I might agree with the statement "Specific statistics must come from a specific source" and thus have no problems with that. 
And the statement if most switches use the L2 or L3 hash is open for discussion; with the amount of multi-layer switches I woulnd't be able to say if they use the L2 hash or L3 hash as implementations tend to use as "hash": based on source/destination MAC or IP address" - which can be both L2 or L3 (including link aggregation implementations on teaming and virtual switches in virtualized environments (ESX, Hyper-V, Nexus 1000v etc))
The only 'comment' on a reference I don't understand is:
http://grouper.ieee.org/groups/802/3/hssg/public/apr07/frazier_01_0407.pdf
What is wrong with this resource?
Thanks,
Tonkie (talk) 00:45, 9 January 2013 (UTC)
replies: text: It is a WP:PRIMARY source because it is a presentation by one of the members of the IEEE 802.3 working group that designed link aggregation. Primary sources are OK in some contexts and this is probably one of them. But it is also self published in that the way these presentations get onto the internet is that the authors upload them to the IEEE website. -—Kvng 03:06, 9 January 2013 (UTC)
thread_title:  Link Aggregation References 

message: Should the corresponding feature of Solaris/Sun cluster be referred to?  — Preceding unsigned comment added by Towopedia (talk • contribs) 09:04, 17 April 2013 (UTC)
thread_title:  Sun cluster 

message: I was surprised that there was no mention of link aggregation on OS X. As a POSIX compliant system, you can aggregate in any POSIX compliant way, but Apple also provides a neat way to aggregate. While I have not tried the following method (copied from this page.) myself, it makes the process sound very easy:
:Go to System Preferences -> Network -> then select the small cog in the bottom left side (next to the + and -) and choose Manage Virtual Interfaces -> select the + in the bottom left and choose New link aggregate. Then you select the two wired interfaces and call it whatever you like. After that it will appear in the network list as one network interface.
Should I blast ahead and add something like this to the existing web page?
StandardPerson (talk)  —Preceding undated comment added 01:24, 27 November 2013 (UTC)
thread_title:  Mac OS X Link Aggregation 

message: Social network aggregation and Media aggregation platform are in "See Also." These don't seem to have anything to do with computer networking. Should they be removed? Daivox (talk) 10:50, 4 August 2015 (UTC)
replies: text: Thank you for your suggestion. When you believe an article needs improvement, please feel free to make those changes.  Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills.  New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to).  -- intgr [talk] 12:00, 26 August 2015 (UTC)
thread_title:  Do these belong in "See Also?" 

message: Hello fellow Wikipedians,
I have just modified one external link on Link aggregation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20121019131903/http://www.linuxfoundation.org/collaborate/workgroups/networking/networkoverview to https://www.linuxfoundation.org/collaborate/workgroups/networking/networkoverview
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 11:47, 16 May 2017 (UTC)
thread_title:  External links modified 

message: For the record, I agree with 's reversion of your recent changes. I read the added paragraph multiple times and it's so incomprehensible, I still don't understand what it's trying to say. Perhaps it's missing some context. -- intgr [talk] 12:57, 30 January 2018 (UTC)
replies: text: I've noticed these spurious additions in various articles. After the first unsourced reverts, Pillzyx started to use various journal sources which, as far as I could verify, are almost entirely unrelated and apparently serve as alibi. His/her edits are designed to make some incomprehensible claims that nobody is supposed to understand. This is subversive, disruptive editing that might be aiming at the heart of WP. --Zac67 (talk) 15:33, 30 January 2018 (UTC)
thread_title:  Confusing addition in lead 

message: Why is channel bonding linked back to same article?  Circular logic? - --KitchM (talk) 18:01, 19 April 2019 (UTC)
replies: text: Removed. ~Kvng (talk) 21:44, 5 June 2019 (UTC)
thread_title:  Channel Bonding 

message: Hi! Sure, some vendors probably have extensions to the standard link aggregation, but is it really fair to say that Cisco's EtherChannel, Juniper's "Aggregate Ethernet", Avaya/Extreme's MLT and some others are "Proprietary link aggregation"? They work together with each other and as far as I know, Juniper has no special add-ons to the standard. Isn't it more of a terminology thing? At least I think it should be pointed out that most of these work together but some may have additional features beyond the standard and that they fall back to the standard if the partner doesn't understand the extra features. Perhaps changing the heading to "Proprietary additions to link aggregation" would be a better heading? Fb35523 (talk) 10:26, 7 December 2020 (UTC)
replies: text: Your examples are no extensions to IEEE LACP but proprietary methods/protocols, so yes, the heading is good. When links are simply aggregated, without any protocol, those may very well interact with each other nicely, some even with a non-aggregating partner, but their inner workings are proprietary = not defined by an open standard nonetheless. --Zac67 (talk) 11:46, 7 December 2020 (UTC)
thread_title:  Is "Proprietary link aggregation" really a good heading?