Upgrade to 2.1.4 - One CARP interface staying MASTER
-
Hi there,
I just upgraded 2 secondary pfSense firewalls to 2.1.4 - identical hardware, different locations - both are the slaves in their CARP pair.
First one went fine except the package lock got stuck, so I had to manually clear that and do a reinstall of packages - no problems that I can see.
The second firewall, however, believes it's MASTER on one interface and SLAVE on the 3 others. (4 interfaces total - all VLANs over LACP trunk)
All 4 "interfaces" are VLANs attached to a LACP channel comprised of 4 ethernet ports (lagg0_vlan1, lagg0_vlan2, lagg0_vlan3 style), so they are actually the same "physical" interface(s) underneath and should receive the same switchport multicast/etc traffic .
After a bit of tinkering and looking around, I used the 'restore full backup' feature to revert to 2.1.3 - once I rebooted it, it behaved normally once more (but still on 2.1.3).
I've run into multicast issues in the past and the switch has IGMP snooping turned off as a result, plus it behaves perfectly fine on 2.1.3.
The first firewall (which worked, and got the package lock stuck) were installed as 2.1.1 and upgraded to 2.1.2 -> 2.1.3 -> 2.1.4.
The second firewall (CARP issue) was installed as 2.0.3 and upgraded to 2.1.3 directly some time later.
Hardware is identical in both cases and configuration is quite similar (VLAN interfaces over LACP, CARP, etc) but not identical.Any ideas? I'm not sure what to look for or try, really.
-
I have to jump in and agree. Had the same problem. One of four interfaces got a split brain and master and slave both had it active. After upgrading master and rebooting both, that solved, but left a vary feeling…
-
What is the proper upgrade order? Secondary first?
-
If you use IP Alias type VIPs layered on top of CARP VIPs, use the System Patches package to apply this fix (committed this morning):
https://github.com/pfsense/pfsense/commit/2bf2a1c4c9a4ed1c378891e2b0e55edf3ed1a658
-
I've upgraded the backup box only to 2.1.4 an have the same issue.
However, we don't use VLNAs, just IP Aliases as jimp described.With the recommended patch it works as expected again.
-
Please start your own thread for that issue, it's unrelated to this topic.