Bug 199996 - Link Aggregation LAGG: LACP bugs in 10.1
Summary: Link Aggregation LAGG: LACP bugs in 10.1
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Depends on:
Reported: 2015-05-06 14:30 UTC by Mikhail
Modified: 2018-12-19 00:46 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail 2015-05-06 14:30:41 UTC
Initial state:
 1) lagg/lacp is organized between FreeBSD at one side and some network switch at another side (Cisco, Extreme Networks, Dell/Force10, ...)
 2) lagg/lacp is running and state is UP at both sides. For example and for  simplification, there is only one physical link in lagg. At FreeBSD side:

 In case if there is some unidirectional failure occured, and lacp packets are passed only in one direction and doesn't pass in another direction, we expect that LACP protocol will remove such link from lagg interface.
This is true if lacp packets doesn't pass from FreeBSD to some network switch. Then  lacp timeout is occured at switch side  and link is removed from agregat. (OK)
laggport: ix1 flags=0<>

This is not true if lacp packets doesn't pass from network switch to FreeBSD. At the same time lacp packets are transmitted from FreeBSD to network switch, so there is no any lacp timeout occured at switch side. (BUG?) 

How to reproduce: For example, to filter with layer2 acl or something like that egress LACP packets at switch side.
At the same time, tcpdump at FreeBSD shows that incoming LACP packets is gone, only outgoing are present. 
lagg/lacp still UP.

P.S. The same behaviour regardless of net.link.lagg.0.lacp.lacp_strict_mode state.