Bug 202663

Summary: LACP protocol in bridge not forwarding
Product: Networking Reporter: Ehsan (ehsan.tadayon1985)
Component: OtherAssignee: Stephen Hemminger (stephen)
Status: RESOLVED WILL_NOT_FIX    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.4.167 Subsystem:
Regression: No Bisected commit-id:

Description Ehsan 2019-02-24 09:34:35 UTC
Distribution: ubuntu16.04
Problem Description:
The problem comes up when I create a bridge using brctl to make a connection between two virtual machines on qemu-kvm. I want to configure LACP on two different VMs' interfaces, however Hello packets are never forwarded by the Bridge. 

I've downloaded the kernel source and edited the net/bridge/br_input.c  file as below:
################################################
/*
   * See IEEE 802.1D Table 7-10 Reserved addresses
   *
   * Assignment     Value
   * Bridge Group Address  01-80-C2-00-00-00
   * (MAC Control) 802.3  01-80-C2-00-00-01
   * (Link Aggregation) 802.3 01-80-C2-00-00-02
   * 802.1X PAE address  01-80-C2-00-00-03
   *
   * 802.1AB LLDP   01-80-C2-00-00-0E
   *
   * Others reserved for future standardization
   */
  fwd_mask |= p->group_fwd_mask;
  switch (dest[5]) {
  case 0x00: /* Bridge Group Address */
   /* If STP is turned off,
      then must forward to keep loop detection */
   if (p->br->stp_enabled == BR_NO_STP ||
       fwd_mask & (1u << dest[5]))
    goto forward;
   *pskb = skb;
   __br_handle_local_finish(skb);
   return RX_HANDLER_PASS;

  case 0x01: /* IEEE MAC (Pause) */
   goto drop;
+  case 0x02: /* Link Aggregation) */
+   goto forward;
################################################
When I add the aforementioned case statement and compile the kernel, the problem is resolved.
while default case statement must forward other protocol types, it doesn't work correctly.
Comment 1 Stephen Hemminger 2019-02-24 19:49:20 UTC
LACP is in the restricted group forwarding mask.

The Linux bridge allows many things to be forwarded, but STP, LACP and PAUSE
are not allowed to stay conformant with 802.1 standard.

The discussion has come up before on the mailing list, and so far each instance of someone wanting it turned out to be a mistake.