Project

General

Profile

Actions

Bug #7928

closed

LAGG interfaces lose MAC address

Added by Steve Wheeler about 7 years ago. Updated over 6 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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

Actions #1

Updated by Arthur Brownlee IV almost 7 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.)

Actions #2

Updated by Jim Pingle almost 7 years ago

  • Affected Version changed from 2.4 to 2.4.2
Actions #3

Updated by Jim Pingle almost 7 years ago

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

Updated by Jim Thompson almost 7 years ago

  • Assignee set to Luiz Souza
Actions #5

Updated by Denis Grilli almost 7 years ago

Have the same issue in my configuration.

Actions #6

Updated by Denis Grilli almost 7 years 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.

Actions #7

Updated by Luiz Souza almost 7 years 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.

Actions #8

Updated by Luiz Souza almost 7 years ago

  • % Done changed from 0 to 100
Actions #9

Updated by Steve Wheeler almost 7 years ago

Confirmed. This appears resolved in 2.4.2.a.20171024.2153

Actions #10

Updated by Michael OBrien almost 7 years ago

Steve Wheeler wrote:

Confirmed. This appears resolved in 2.4.2.a.20171024.2153

Double-confirmed :)

Actions #11

Updated by Luiz Souza almost 7 years ago

  • Status changed from Feedback to Resolved
Actions #12

Updated by Gianluca Toso almost 7 years 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.

Actions #13

Updated by Gareth Jones almost 7 years 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

Actions #14

Updated by Steve Wheeler almost 7 years 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.

Actions #15

Updated by Olivier Delcourt over 6 years 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

Actions #16

Updated by Steve Wheeler over 6 years 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?

Actions #17

Updated by Olivier Delcourt over 6 years 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).

Actions

Also available in: Atom PDF