IBM Support

Configuring Ethernet Link Aggregation



This document contains information on configuring Ethernet Link Aggregation.

Resolving The Problem

This document contains information on configuring Ethernet Link Aggregation.

Link Aggregation takes several full-duplex Ethernet links running at the same speed and binds them together into one logical link with a single Media Access Control (MAC) address. This provides two main advantages: improved reliability through transparent failover and aggregated throughput.

If any of the links lose their connection, the IBM i support will transmit outgoing frames on other links as long as there are any up, and the link partner will do the same for incoming frames. This provides transparent fail over on a per-frame basis, usually without affecting any running workloads. For example, given a four-port aggregate, if one link goes down, the traffic that would have traveled on that link will
be handled by the remaining three links. If any links are operational, the aggregate will continue to function.

In addition, each operational aggregated link can run at the configured line speed, and outgoing traffic will be spread according to a configured preference. (Incoming traffic will be spread across the links according to configuration at the link partner.) Many workloads (especially those with multiple parallel TCP or UDP conversations) can take advantage of this to scale their throughput with the number of available ports.

1.Preparing to create an aggregate line description.

Before creating an aggregate line description, you should select the Ethernet resources that will be aggregated (up to eight ports can be aggregated in one line description.)

o None of the ports can be in use by another line description, LAN console, or remote support.

o All of the ports must support full duplex and the desired line speed (as well as supporting 1Gbps or higher, even if that is not the desired line speed).

o All of the ports must be connected to the same link partner (switch).

o All of the corresponding ports on the link partner must be configured in a static aggregation.
NOTE: LACP is now supported with TR7 for R710

No more than 255 aggregate line descriptions can exist in the partition. If more are desired, you should delete existing aggregate line descriptions.

The following PTFs are required for this functionality:
2.Creating an aggregate line description.

An aggregated link is created by using the CRTLINETH command. The following parameters are relevant to aggregation:

o Resource Name (RSRCNAME): set to new special value *AGG to indicate aggregation

o Duplex (DUPLEX): Half duplex is not supported

o Aggregated Resource List (AGGRSCL): up to 8 Ethernet port resource names (starting with CMN) with the restrictions laid out in the previous section

o Aggregate Policy (AGGPCY): A standard and a policy type for outgoing frames.
*ETHCHL -indicating a static configuration that is not negotiated with the partner.
*LNKAGG - LACP negotiation where the link is negotiated and periodic heartbeats are used to monitor physical link status

IBM i Link Aggregation has been tested while connected to a Cisco Catalyst switch. Other switches that support static aggregation/LACP configurations may also work; however, they were not tested and are not officially supported.

The policy type indicates how data should be spread for outgoing frames. Most IBM i users will probably get the most benefit from *SRCDESTP, which uses information about both ends of a TCP or UDP conversation to determine which link to use for each outgoing frame.

Important Note: *RNDRBN is the only policy that does not bind a conversation to a path. It will spread the data out among all of the paths. In doing so, it introduces the possibility that outgoing frames will be received out of order by the other side, which would cause significant delays in TCP workloads because of congestion recovery (retransmissions, and so on).

For example, to create a two-port aggregate: you should issue the following command:

3.Managing an aggregate line description.

Once it is created, an aggregate line description can be used in the same way as a non-aggregate line description would be. For example,
ADDTCPIFC can be used to create an IP interface that will send its traffic through the new line description.

A non-aggregate line description cannot be changed to an aggregate line description, nor can an aggregate be changed later into a non-aggregate. AGGPCY and AGGRSCL can be changed using CHGLINETH; however, it cannot be changed while the line description is active.

Once the line description is varied on, the aggregation status of each resource can be viewed on a new panel from the DSPLIND command. This can be used to monitor for any links that are not operational.

When an aggregate line description is varied on, a new resource with type 6B26 may appear in WRKHDWRSC. Resources with type 6B26 are not valid for configuration by line descriptions or for LAN console or remote support. When an aggregate line description is deleted, a resource with type 6B26 may disappear from WRKHDWRSC.
Note: Performance: Link aggregation support carries some processing overhead. In addition, depending on what combination of resources are in the aggregate, some advanced performance features of the aggregated resources may be disabled. (For example, if some aggregated resources support TCP large send offload over IPv6, but others do not, the aggregate will not support TCP large send offload over IPv6.)

[{"Type":"MASTER","Line of Business":{"code":"LOB57","label":"Power"},"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Platform":[{"code":"PF012","label":"IBM i"}],"Version":"7.1.0"}]

Historical Number


Document Information

Modified date:
18 December 2019