Project

General

Profile

Bug #7928

LAGG interfaces lose MAC address

Added by Steve Wheeler almost 2 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Interfaces
Target version:
Start date:
10/11/2017
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.x
Affected Architecture:

Description

LAGG interfaces lose their MAC address, normally inherited from the first member, if all links are disconnected and then reconnected. The switch they are connected to is powercycled for example.

Create a lagg interface with two memebers. Set it to LACP. Check the MAC of lagg0 it will be 00:00:00:00:00:00.

Reboot the firewall it will come back up with the correctly inherited MAC.

Pull the links to the two members NICs. The MAC will remain correct. Reconnect one or both members and the MAC will revert to 00:00:00:00:00:00

Additonally editing an existing lagg anf changing its type, for example, will result in a void MAC.

This does not happen in 2.3.4

Associated revisions

Revision 9875c199 (diff)
Added by Luiz Souza over 1 year ago

Do no set the MAC address for LAGG interfaces.

Ticket #7928

Revision b839aa8a (diff)
Added by Luiz Souza over 1 year ago

Do no set the MAC address for LAGG interfaces.

Ticket #7928

(cherry picked from commit 9875c1999bd546a6982e6d98309b6fc53db145b6)

History

#1 Updated by Arthur Brownlee IV almost 2 years ago

Can confirm, this is new behavior and I am able to duplicate it per Steve's steps at a client site. The secondary firewall (same hardware, but left on 2.3.x for now, functions normally.)

#2 Updated by Jim Pingle over 1 year ago

  • Affected Version changed from 2.4 to 2.4.2

#3 Updated by Jim Pingle over 1 year ago

  • Target version set to 2.4.2
  • Affected Version changed from 2.4.2 to 2.4.x

#4 Updated by Jim Thompson over 1 year ago

  • Assignee set to Luiz Souza

#5 Updated by Denis Grilli over 1 year ago

Have the same issue in my configuration.

#6 Updated by Denis Grilli over 1 year ago

You can also have the problem if you have vlans attached to the lagg interface:

1) create a new vlan
2) assign the new vlan to an interface.

After step 2) you lose the mac address.

I would consider to change priority to this case. It feels to me a quite of a big problem.

#7 Updated by Luiz Souza over 1 year ago

  • Status changed from New to Feedback

A fix was committed to address this issue, please wait until the next 2.4.2 snapshot is ready and let me know if it doesn't work.

#8 Updated by Luiz Souza over 1 year ago

  • % Done changed from 0 to 100

#9 Updated by Steve Wheeler over 1 year ago

Confirmed. This appears resolved in 2.4.2.a.20171024.2153

#10 Updated by Michael OBrien over 1 year ago

Steve Wheeler wrote:

Confirmed. This appears resolved in 2.4.2.a.20171024.2153

Double-confirmed :)

#11 Updated by Luiz Souza over 1 year ago

  • Status changed from Feedback to Resolved

#12 Updated by Gianluca Toso over 1 year ago

Hi,
I had similar issue with this mb APU1D/T40E, pfsense 2.4.0 fresh install:
all 3 reX interfaces were members in a LAG (LACP) which also contained several VLANs.
All interfaces showed mac address 00:00:00:00:00:00, this caused troubles with DHCP, PPPoE and so on...
Same config with 2.3.4 nanobsd works like a charme.
I didn't perform upgrade to 2.4.1 because I needed PPPoE over VLAN.
Therefore on a different 8 ports motherboard with emX nics the mac address problem doesn't occur (similar config with 6 over 8 port in a LACP LAG with server VLANs).

Will the 2.4.2 fix resolve mac address issue in this scenario as well?

Thanks in advance,
regards.

#13 Updated by Gareth Jones over 1 year ago

Similar issue here with 2.4.1 and 2.4.2. using LAG groups for statefull failover where nic on two generations of APU based firewalls are different. RE2 nic shows 00:00... even after reboot on 2.4.2

#14 Updated by Steve Wheeler over 1 year ago

Just the re2 NIC or the lagg interface also?

That sounds like a different issue if the parent NIC is actually losing it's MAC.

Open a thread to troubleshoot on the forum if you haven't already.

#15 Updated by Olivier Delcourt about 1 year ago

I have the same problem with pfsense 2.3.5 (fresh install nanobsd on a netgate apu1C4).
I there a fix or workaround I can use for 2.3.5 ?
thx

#16 Updated by Steve Wheeler about 1 year ago

Hmm, we never saw this in 2.3.X previously.

Do you see it in 2.3.5p2 if you haven't tested that already?

Were you running this in another version previously?

#17 Updated by Olivier Delcourt about 1 year ago

Yes I have it with a 2.3.5p2 (fresh install). Never try to do it before (as I hadn't a LACP compliant ethernet switch before).

Also available in: Atom PDF