Bug #12926
openChanging LAGG type on CARP interfaces makes VIPs go to an "init" State
0%
Description
When changing a LAGG from any mode to another mode while it has child interfaces that are something like VLANs and CARP VIPs on them will cause CARP to go to an init status and never recover.
If you re-save the interface or reboot the firewall, they will go back to MASTER or BACKUP (depending on if it's primary or secondary). This can be worked around by failing over manually before making these changes and rebooting the firewall you're working on to avoid disruption, but this seems like a bug that should not present itself.
Bug was present in 2.6 of CE and 22.01 of pfSense Plus.
Updated by Viktor Gurov 4 months ago
- Status changed from New to Feedback
- Affected Version set to 2.6.0
Unable to reproduce:
lagg0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: OPT2 options=6900bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether de:e1:87:63:8d:8a inet6 fe80::dce1:87ff:fe63:8d8a%lagg0 prefixlen 64 scopeid 0xc laggproto lacp lagghash l2,l3,l4 laggport: vtnet3 flags=0<> groups: lagg media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lagg0.11: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: VLAN11 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether de:e1:87:63:8d:8a inet6 fe80::dce1:87ff:fe63:8d8a%lagg0.11 prefixlen 64 scopeid 0xd inet 10.22.22.100 netmask 0xffffff00 broadcast 10.22.22.255 inet 10.22.22.22 netmask 0xffffff00 broadcast 10.22.22.255 vhid 1 groups: vlan carp: MASTER vhid 1 advbase 1 advskew 0 vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
after changing the LAGG mode from LACP to ROUNDROBIN:
lagg0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: OPT2 options=6900bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether de:e1:87:63:8d:8a inet6 fe80::dce1:87ff:fe63:8d8a%lagg0 prefixlen 64 scopeid 0xc laggproto roundrobin lagghash l2,l3,l4 laggport: vtnet3 flags=4<ACTIVE> groups: lagg media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> lagg0.11: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: VLAN11 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> ether de:e1:87:63:8d:8a inet6 fe80::dce1:87ff:fe63:8d8a%lagg0.11 prefixlen 64 scopeid 0xd inet 10.22.22.100 netmask 0xffffff00 broadcast 10.22.22.255 inet 10.22.22.22 netmask 0xffffff00 broadcast 10.22.22.255 vhid 1 groups: vlan carp: MASTER vhid 1 advbase 1 advskew 0 vlan: 11 vlanpcp: 0 parent interface: lagg0 media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
Please provide more details about this issue.
Updated by Kris Phillips 4 months ago
Viktor Gurov wrote in #note-1:
Unable to reproduce:
[...]after changing the LAGG mode from LACP to ROUNDROBIN:
[...]Please provide more details about this issue.
Viktor,
When testing with a customer, they had several dozen VLAN interfaces (around 50). Likely this is needed to trigger this.