[f-nsp] LACP with Foundry and Linux Machine

tcsillag at interware.hu tcsillag at interware.hu
Sat Apr 5 06:49:15 EDT 2014


I think Foundry can violate that part a bit with the "Server trunk"
option, as that restriction of LACP is pretty painful with something like
iSCSI, where I'd really like to use multiple Gig interfaces for one flow.

http://www.foundrynet.com/services/documentation/sribcg/current/Trunking.html#wp112750

Tamas


> Is this a single TCP/UDP connection?  The spec requires LACP to use a
> hash that guarantees a given flow will always hash to the same
> interface.  For LACP to work effectively, you need multiple flows.
>
> --
> Eldon Koyle
> Information Technology
> Utah State University
> --
> BOFH excuse #175:
> OS swapped to disk
>
> On  Apr 04 19:35+0545, Rupesh Basnet wrote:
>> Hi All,
>>
>> L3 hashing mode is not helping on my case, there are only one way
>> traffic on two interfaces and I am not able to figure out issue. Is
>> server mode trunk a L3 hashing mode on foundry?
>>
>>
>> Regards,
>> --------
>> Rupesh Basnet
>>
>>
>> On 2014-04-01 10:58, George B. wrote:
>> >I tend to use layer3+4 because for the average server the majority of
>> >the traffic is going to its default gateway so that always gets
>> >hashed
>> >to the same link when using layer2 hashing.  Layer3-4 will at least
>> >hash it based on destination source port and IP address and as most
>> >client connections come from a wide range of source ports, that more
>> >effectively balances the traffic across the links.
>> >
>> >On Mon, Mar 31, 2014 at 10:08 PM, Frank Bulk <frnkblk at iname.com [9]>
>> >wrote:
>> >
>> >>You can't control the hashing on inbound, but you can configure the
>> >>outbound.
>> >>
>> >>For the Linux machine there appears to be two options: layer2 or
>> >>layer3+4
>> >>
>> >
>> >(http://www.cyberciti.biz/howto/question/static/linux-ethernet-bonding-drive
>> >>r-howto.php).
>> >>
>> >>Frank
>> >>
>> >>-----Original Message-----
>> >>From: foundry-nsp [mailto:foundry-nsp-bounces at puck.nether.net [1]]
>> >>On Behalf Of
>> >>Rupesh Basnet
>> >>Sent: Monday, March 31, 2014 11:57 PM
>> >>To: Raoul Bhatia; Erich Hohermuth
>> >>Cc: foundry-nsp at puck.nether.net [2]
>> >>Subject: Re: [f-nsp] LACP with Foundry and Linux Machine
>> >>
>> >>Hi Raoul,
>> >>
>> >>With trunk on foundry and mode 4 on linux box with load balancing
>> >>on l2
>> >>hash mode, load balance was happening is asymmetric way. IN traffic
>> >>was
>> >>seen from one and  OUT traffic was seen from another interface. I
>> >>think
>> >>server mode on foundry might help but it seems we need to reload to
>> >>reconfigure it. Are there any way out for proper load balancing?
>> >>
>> >>Regards,
>> >>--------
>> >>Rupesh Basnet
>> >>
>> >>System Operations
>> >>Subisu Cablenet (P.) Ltd.
>> >>148 Thirbum Sadak
>> >>Baluwatar, Kathmandu
>> >>Nepal
>> >>
>> >>T: 00977 1 4429616/17 Ext.: 322,323(4412832-Direct Line)
>> >>F: 00977 1 4430572
>> >>
>> >>http://www.subisu.net.np [3]
>> >>
>> >>(An ISO 9001:2008 Certified Company)
>> >>
>> >>On 03/30/2014 11:41 AM, Raoul Bhatia wrote:
>> >>> On 30 March 2014 07:12:08 CEST, Rupesh Basnet
>> >><brupesh at subisu.net.np [4]>
>> >>wrote:
>> >>>> Hi Erich,
>> >>>>
>> >>>> I tried changing LACP rates with mode 4 but status was the same
>> >>and
>> >>>> linux box was also not able to get partner MAC on its
>> >>aggregation
>> >>>> status. I tried with balance-rr mode as well but same, only
>> >>single MAC
>> >>>> was obtained under Load Balancing on foundry. I can pass traffic
>> >>from
>> >>>> the bonded interface but still don't have any idea if those
>> >>interfaces
>> >>>> are really bonded and load balance is happening.
>> >>> Hi,
>> >>>
>> >>> It has been some time since I was last configuring bonding but I
>> >>*think*
>> >>that balancing happened on the basis of MAC addresses, (or even
>> >>ports?) or
>> >>some other part of the packet header.
>> >>>
>> >>> So while testing, you might see balancing only after using
>> >>multiple
>> >>streams and source/destination MACs.
>> >>>
>> >>> Cheers,
>> >>> Raoul
>> >>
>> >>_______________________________________________
>> >>foundry-nsp mailing list
>> >>foundry-nsp at puck.nether.net [5]
>> >>http://puck.nether.net/mailman/listinfo/foundry-nsp [6]
>> >>
>> >>_______________________________________________
>> >>foundry-nsp mailing list
>> >>foundry-nsp at puck.nether.net [7]
>> >>http://puck.nether.net/mailman/listinfo/foundry-nsp [8]
>> >
>> >
>> >
>> >Links:
>> >------
>> >[1] mailto:foundry-nsp-bounces at puck.nether.net
>> >[2] mailto:foundry-nsp at puck.nether.net
>> >[3] http://www.subisu.net.np
>> >[4] mailto:brupesh at subisu.net.np
>> >[5] mailto:foundry-nsp at puck.nether.net
>> >[6] http://puck.nether.net/mailman/listinfo/foundry-nsp
>> >[7] mailto:foundry-nsp at puck.nether.net
>> >[8] http://puck.nether.net/mailman/listinfo/foundry-nsp
>> >[9] mailto:frnkblk at iname.com
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp at puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
>





More information about the foundry-nsp mailing list