Lagg interface using LACP proto

M

mlager

Hi there,

I've got 3 identical servers, each with two gigabit interfaces plugged into a Dell PowerConnect 2824 switch. Each pair of ports is configured in a static LAG configuration. I then create the lagg0 interface on the servers, configure addresses, and everything is good to go. Connectivity is fine, ifconfig shows each interface is active, collecting, and distributing, and fail over works fine. I can down interface 1, and interface 2 picks up all of the traffic.

Server 1 isn't distributing the traffic across both interfaces the same way servers 2 and 3 are. Server 1 is sending and receiving all traffic on interface 1 whereas servers 2 and 3 are receiving inbound traffic on interface 1 and sending outbound traffic on interface 2.

I guess my question is, what are the rules when when it comes to traffic distribution? What would cause server 1 to act differently than the others? Is the distribution based on load, or should it always be even? Also, after a fail over to interface 2, will traffic distribute evenly once interface 1 comes back up or will I have the reload lagg0 for that to happen? I'm assuming failover also only occurs for physical link disruption, not lack of connectivity.

Thanks for any clarification, the man page is useful, but not elaborate.

Matt
 
Your thread title says you're using LACP, but your post says you're using a static LAG configuration. Which is it? Maybe post your config for clarification.

Over here I use LACP with two NICs connected to an HP V1900. Outgoing traffic from FreeBSD flows evenly over both interfaces. Sadly the switch just throws all incoming traffic down one of the interfaces at a time in a slow round robin fashion. I've only tested with one IP flow at a time though... multiple simultaneous IP flows may get balanced better.
 
Your reply does a good job of showing that I am not fully understanding this :) The switch allows me to group ports into what they call LAG groups. These groups have a type of "static" which I'm not able to change to anything else. This may mean that the switch doesn't support the LACP protocol? Nevertheless, the freebsd servers are configured with laggproto lacp and appear to be functioning to some degree, except for the server 1 which isn't distributing the traffic in any way.

So i am assuming that me using lacp doesn't make much sense seeing that the switch isn't doin lacp. I am not exactly sure what static mode is, maybe some clarification of that may help me, and understanding my best option in freebsd to do load balancing between the two networks interfaces. I see another option called round robin, but the man page shows that as needing to be used with caution, so that worries me.

Thanks again.
 
There are two types of LACP trunks: dynamic and static. Both use the LACP protocol, and both work basically the same. The only difference is how client NICs join the trunk.
 
Mmm, I'm not 100% sure, but I've always considered LACP to be dynamic LAG, as opposed to round-robin, fail-over, and balance algorithms being static. Never heard of static LACP. Wasn't LACP developed for the sole purpose of achieving dynamic reconfiguration in the event of physical connectivity changes?

mlager, I looked at your switch's specs and it doesn't seem to support LACP, but supports other parts of 802.3ad, ie. static LAG. Try the other laggproto options on your lagg device. Where in the man page is caution given to roundrobin?
 
Our HP ProCurve's support dynamic or static LACP trunks. Both work with lagg(4) using laggproto lacp, with traffic balancing across the interfaces.

The only issue I've come across with using static LACP on the switch is that I can't temporarily break the lagg interface on the server to test things (leave main NIC connected, add other NIC to separate vlan, etc).

Basically, static LACP trunking just configures the switch ports to always be part of a bonded trunk. And then the NICs connected to those ports also have to configured as a static LACP trunk.
 
Thx for the info, I ended up just enabling round robin mode on the lagg as it was the only mode that rendered results that I would have expected. In LACP, things were spotty. Round robin evenly distributes outgoing traffic to both interfaces, and provides the fault tolerance I desire, so until I get a switch that better supports LACP, that's where I'll sit :)

Thanks again!
 
You must log in or register to reply here.
Back
Top