Project

General

Profile

Actions

Bug #3976

closed

VLAN Interfaces on LAGG get orphaned on LAGG change

Added by Jens Weibler over 9 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
Start date:
11/03/2014
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1.5
Affected Architecture:

Description

Reproduce:

1. Create LAGG with e.g. em3 + em4, LACP and a nice description
2. Create a few vlans and assign them to your LAGG-device
3. Think about a nicer description and change the LAGG-device again. Now all your vlan interfaces on the lagg are orphaned and have no parent (device) anymore.

lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether <DELETED>
        inet6 <DELETED> prefixlen 64 scopeid 0xf
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        media: Ethernet autoselect
        status: active
        laggproto lacp
        laggport: em3 flags=18<COLLECTING,DISTRIBUTING>
        laggport: em2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

lagg1_vlan15: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15                                                                                        00
        options=103<RXCSUM,TXCSUM,TSO4>
        ether <DELETED>
        inet6 <DELETED>%lagg1_vlan15 prefixlen 64 scopeid 0x11
        inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
        nd6 options=1<PERFORMNUD>
        media: Ethernet autoselect
        status: active
        vlan: 15 vlanpcp: 0 parent interface: lagg1

Afterwards

lagg1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
        ether <DELETED>
        inet6 <DELETED>%lagg1 prefixlen 64 scopeid 0xf
        nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
        media: Ethernet autoselect
        status: active
        laggproto lacp
        laggport: em4 flags=0<>
        laggport: em2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

lagg1_vlan15: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=103<RXCSUM,TXCSUM,TSO4>
        ether <DELETED>
        inet6 <DELETED>%lagg1_vlan15 prefixlen 64 scopeid 0x11
        inet 192.168.15.1 netmask 0xffffff00 broadcast 192.168.15.255
        nd6 options=1<PERFORMNUD>
        vlan: 0 vlanpcp: 0 parent interface: <none>

See also https://forum.pfsense.org/index.php?topic=83605.0

First I thought it only happens on changing the LAGG members. But just changing the description is enough. If this bug (if you need a name - how about batman bug?) can't be fixed, I suggest a big fat warning on the LAGG configuration page.

Actions #1

Updated by Chris Buechler over 9 years ago

  • Status changed from New to Resolved
  • Target version set to 2.2

that is replicable on 2.1.x but not 2.2, already fixed there.

Actions #2

Updated by David Farrugia about 8 years ago

I can reproduce this at will on embedded alix2d13 running 2.2.6-RELEASE (i386):

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=8280b<RXCSUM,TXCSUM,VLAN_MTU,WOL_UCAST,WOL_MAGIC,LINKSTATE>
        ether <REMOVED>
        inet6 <REMOVED> prefixlen 64 scopeid 0x8
        inet <REMOVED> netmask 0xffffff00 broadcast 192.168.17.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        media: Ethernet autoselect
        status: active
        laggproto lacp lagghash l2,l3,l4
        laggport: vr2 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>
        laggport: vr1 flags=1c<ACTIVE,COLLECTING,DISTRIBUTING>

lagg0_vlan9: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:00:00:00:00:00
        inet6 <REMOVED> prefixlen 64 scopeid 0xa
        inet <REMOVED> netmask 0xffffff00 broadcast 192.168.18.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        vlan: 0 vlanpcp: 0 parent interface: <none>

lagg0_vlan10: flags=8803<UP,BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 00:00:00:00:00:00
        inet6 <REMOVED> prefixlen 64 scopeid 0x9
        inet <REMOVED> netmask 0xffffff00 broadcast 192.168.19.255
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        vlan: 0 vlanpcp: 0 parent interface: <none>

the vlanid is 0 and interface is none in such cases. Sadly this happens on every reboot or alteration to the LAGG. This is the first time I'm using such a setup on pfsense, thus I don't know if this ever worked before on this platform.

Any one else manage to reproduce this?

Actions #3

Updated by Chris Buechler about 8 years ago

David Farrugia wrote:

Any one else manage to reproduce this?

It regressed in 2.3 and was fixed there on a separate ticket. Didn't think that went back to 2.2.6 but apparently it did judging by your description. It's definitely fine in 2.3 though.

Actions #4

Updated by David Farrugia about 8 years ago

Thanks Chris, the difference in my case is that rebooting the device yields the same issue ie. the vlans interfaces are orphaned, possibly due to the renaming of the lagg / vlan interfaces, not sure though.

What I do to fix this is, disable 1 of the vlans for the UI and re-enable it. This reconfigures all vlans properly.

Actions #5

Updated by David Farrugia about 8 years ago

Chris, this issue is still present for me on 2.3 nanobsd release (updated today). I can only reproduce this AFTER a reboot. I am still able to connect with the box since my LAN interface is the untagged traffic on the LAGG. Please let me know what is needed from me (log, etc.) to help reproduce / fix this issue.

Actions #6

Updated by Chris Buechler about 8 years ago

David: your issue isn't related to this in that case. could you send me a copy of your config backup? cmb at pfsense dot org.

Actions

Also available in: Atom PDF