Bug #7928
closed
LAGG interfaces lose MAC address
100%
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
Updated by Arthur Brownlee IV over 6 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.)
Updated by Jim Pingle over 6 years ago
- Affected Version changed from 2.4 to 2.4.2
Updated by Jim Pingle over 6 years ago
- Target version set to 2.4.2
- Affected Version changed from 2.4.2 to 2.4.x
Updated by
Updated by Denis Grilli over 6 years ago
Have the same issue in my configuration.
Updated by Denis Grilli over 6 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.
Updated by Luiz Souza over 6 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.
Updated by Steve Wheeler over 6 years ago
Confirmed. This appears resolved in 2.4.2.a.20171024.2153
Updated by Michael OBrien over 6 years ago
Steve Wheeler wrote:
Confirmed. This appears resolved in 2.4.2.a.20171024.2153
Double-confirmed :)
Updated by Luiz Souza over 6 years ago
- Status changed from Feedback to Resolved
Updated by Gianluca Toso over 6 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.
Updated by Gareth Jones over 6 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
Updated by Steve Wheeler over 6 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.
Updated by Olivier Delcourt almost 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
Updated by Steve Wheeler almost 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?
Updated by Olivier Delcourt almost 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).