Jump to content

Talk:Link aggregation/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Redirects to this page

The following redirects have been created that link to this article:

  • 802.3ad
  • ethernet trunk
  • ethernet trunking
  • link aggregate group
  • NIC teaming
  • port trunking
  • port teaming

Deleted this

Some low-cost switches will typically have 24 or 48 10/100-mbit ports, and two additional gigabit ports for the backbone. The expected usage is that there is a 1-gigabit backbone, and the second gigabit port passes the backbone data along to the next switch in the network closet.
While the two 1-gigabit ports may support operating as a single 2-gigabit trunk, there is no way for the switch to pass this 2-gigabit trunk along to additional switches. For a network with an expected maximum backbone speed of 2-gigabits, this is acceptable in a remote closet that can be fully served by the single switch with only 24 or 48 10/100-mbit ports. It is also acceptable if there a lot of switches in a closet and a single expensive switch can be used to manage all their uplinks.

We probably all know which switch he is describing and it should be patently obvious that if you are using this switch and decide to use BOTH of the gig ports for a downlink, then you won't have any ports left over to uplink. This has nothing to do with Link Aggregation and clearly not a limitation of it.

Linux Support and IP Based Load Balancing / Failover

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)

What about uplink?

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)

Network Availability

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)

There is a mention of it, but it only protects against link failures not equipment failures. Plugwash 22:28, 14 October 2006 (UTC)

The LACPDU mechanism actually is a quite good protection against equipment failures. —Preceding unsigned comment added by 188.174.67.0 (talk) 23:54, 24 April 2011 (UTC)

Limitations

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)

Added a paragraph of limitations 210.131.130.125 (talk) 06:51, 13 April 2008 (UTC)

Cisco have Nexus hardware (7xxx switch series, NX-OS soft) with vPC, 2 different switches could be made as a single switch for LA. Virtual PortChannels: Building Networks without Spanning Tree Protocol — Preceding unsigned comment added by 193.33.123.14 (talk) 08:42, 11 July 2011 (UTC)

Earth to Experts that wrote this - COME IN PLEASE!!!

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)

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)

Advantages over static configuration - confusing?

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)

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)

Another redirect

Redirecting 'ethernet bonding' here would be good. 83.27.231.169 20:15, 31 August 2006 (UTC) Kosma

Redirect was created 23:54, 13 February 2008. -—Kvng 15:22, 7 January 2013 (UTC)

Path Polarization Definition?

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)

I expect you are referring to the following passage:

The actual benefits vary based on the load-balancing method used on each device (administrators can configure different balancing algorithms at each end and this is actually encouraged to avoid path polarization).

I don't know who added this and what the thoughts behind the formulation were. However, many simple devices deploy the XOR algorithm described in the article. SA XOR DA is the same as DA XOR SA (SA=Source Address, DA=Destination Address). Since many network admins are tidy when patching, they will often end up connecting the lowest port on one switch to the lowest port on the other etc, ending up with e.g. port 20<=>port 20, 21<=>21, 22<=>22, 23<=>23; for a 4 link aggregate.

In that situation the same conversation between two end stations would flow back and forth on the same link instead of two different ones. I don't see what would be wrong with that, a large (20-30 in most cases) number of conversations will still provide a relatively even distribution. Crossing between ports can help in this case; 20<=>22, 21<=>23, 22<=>21, 23<=>20 for example.

Traffic flowing in one direction will normally not limit traffic flowing in the opposite direction on the same link, unless the link is half duplex. However, IEEE 802.1AX prohibits the use of half duplex links, so that will not be an issue.

EDIT: It occurred to me that when using layer 2 and layer 3 load distribution at the same time there can be a bigger issue. For example with ECMP on layer 3 and LACP on layer 2, having 2 ECMP routes being balanced towards 2 LACP aggregates with each 2 links. If for example using XOR for load sharing, this would send all the conversations to the first route into the first link of that aggregate, and the conversations to the second route into the second link of that aggregate. Some people appear to use the term polarization for this effect. One way around it would indeed be to use different "hashing" algorithms (one based on IP, the other on MAC addresses for example). Another would be to use 3 links in each LACP aggregate when using 2 routes in ECMP.

As I said, I do not know which thoughts the author had in mind at the time of writing, perhaps something I have overlooked. But I thought I'd contribute a possible explanation.

Michael —Preceding unsigned comment added by 80.57.199.198 (talk) 20:01, 24 January 2011 (UTC)

I have trimmed this section to remove unsupported and confusing information. -—Kvng 15:38, 7 January 2013 (UTC)

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:

<ref>http://grouper.ieee.org/groups/802/3/hssg/public/apr07/frazier_01_0407.pdf{{rs|date=January 2013|reason=[[WP:PRIMARY]],[[WP:SPS]]}}</ref> What is wrong with this resource?

Thanks, Tonkie (talk) 00:45, 9 January 2013 (UTC)

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)

OSI layer

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)

I would generally agree with the answer above, with the expansion that link aggregations need not be on trunks. (That view may be due to confusion caused by a vendor who uses the term trunk for a connection that uses 802.1q tags and access for other ports. More generally a trunk connects switching systems and often, but not universally, uses 802.1q tags to carry separate vlans or services. Similarly, a "access port" may use 802.1q tags to provide access to separate vlans or services.) Link aggregation may be optionally used for either trunks between network elements or for edge connections; it is not limited to trunks.

The confusion may have been caused by a problem in the article -- the third paragraph discusses ISO layers, and intermixes the idea of aggregations at different layers with the issue of using data from different layers of the data to determine the spreading of the data across the multiple members of a link aggregation group (LAG). That paragraph needs to be reworked to separate these concepts. Alan Larson (talk) 03:23, 25 January 2013 (UTC)

Sun cluster

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)

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)

Do these belong in "See Also?"

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)

@Daivox: Information icon 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)

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:47, 16 May 2017 (UTC)

Confusing addition in lead

@Pillzyx: For the record, I agree with Zac67'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)

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)

Channel Bonding

Why is channel bonding linked back to same article? Circular logic? - --KitchM (talk) 18:01, 19 April 2019 (UTC)

Removed. ~Kvng (talk) 21:44, 5 June 2019 (UTC)

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)

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)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Link_aggregation/Archive_1&oldid=1290593038"