I have a 9600 and a 9700 joined with a 3 gig LACP link between two SAN servers. Problem is, that the agg seems to be hammering just the prime link, while the othere two members are trickling along. (Before anybody asks, it is configured for 4 links)
Is there any way that the link can be persuaded to spread the traffic over all three links S/w = 6.4.3
Thanks
LACP load distribution
-
Sidlahar
Re: LACP load distribution
Hi chris141047,
no, there is no possibility to change the packet distribution (on R6.4.x) over all links. All Broadcast, Multicast and unknown Unicast will be forwarded on the primary link. The packet flow of two devices will always use one link, e.g. every packet of the packet flow from Server A to Server B will use the same link, the packets of the flow Server A to Server C may use the other link. There is no kind of round-robin for the packets. It seems to be a bit different on the OS6900 (R7.2.x) where you can configure a few more parameters.
I hope I am right, but this is how I understand the behavior of LACP on the ALUs...
Best regards
Sidlahar
no, there is no possibility to change the packet distribution (on R6.4.x) over all links. All Broadcast, Multicast and unknown Unicast will be forwarded on the primary link. The packet flow of two devices will always use one link, e.g. every packet of the packet flow from Server A to Server B will use the same link, the packets of the flow Server A to Server C may use the other link. There is no kind of round-robin for the packets. It seems to be a bit different on the OS6900 (R7.2.x) where you can configure a few more parameters.
I hope I am right, but this is how I understand the behavior of LACP on the ALUs...
Best regards
Sidlahar
-
devnull
Re: LACP load distribution
Command you search for is "hash-control" unfortunatly it is not available on a 9000 nonE:
Platforms Supported
OmniSwitch 6400, 6850, 6850E, 6855, 9000E.
Sidlahar is right: with hash-control brief a flow between two Servers will allways be on one link (i think it is based on hashing sorce/dest-mac, may be destination mac only).
Even with hash-control extended you will have one session only on one link, but other sessions from the same source to the same destination may use another link (udp/tcp port hashed)
So only with a big number on connections between different sources/destinations you will have a more or less perfect balancing. Single Flows (Backupserver) are better on big links (10G) or other hardware..
Platforms Supported
OmniSwitch 6400, 6850, 6850E, 6855, 9000E.
Sidlahar is right: with hash-control brief a flow between two Servers will allways be on one link (i think it is based on hashing sorce/dest-mac, may be destination mac only).
Even with hash-control extended you will have one session only on one link, but other sessions from the same source to the same destination may use another link (udp/tcp port hashed)
So only with a big number on connections between different sources/destinations you will have a more or less perfect balancing. Single Flows (Backupserver) are better on big links (10G) or other hardware..
-
sputniki
Re: LACP load distribution
Is the "hash-control" policy responsible for VFL-ports too? (f.e. on OS6900)devnull wrote: Sidlahar is right: with hash-control brief a flow between two Servers will allways be on one link (i think it is based on hashing sorce/dest-mac, may be destination mac only).
Even with hash-control extended you will have one session only on one link, but other sessions from the same source to the same destination may use another link (udp/tcp port hashed)
So only with a big number on connections between different sources/destinations you will have a more or less perfect balancing. Single Flows (Backupserver) are better on big links (10G) or other hardware..
