Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Nov 2020 15:46:06 -0800
From:      Eric Joyner <erj@freebsd.org>
To:        mike tancsa <mike@sentex.net>
Cc:        lev@freebsd.org, current <current@freebsd.org>
Subject:   Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
Message-ID:  <CAKdFRZjeY0QyE4w6D8eD0xBHJ4jX9goo5NqMpb10nFdqUh-e%2BA@mail.gmail.com>
In-Reply-To: <05a17072-570a-6e05-d3e6-802b3bf30e57@sentex.net>
References:  <88004d48-4434-875a-5a36-0627b00c2f38@gmail.com> <1906251966.36777.1590562439792.JavaMail.open-xchange@opme11oxm03aub.bagnolet.francetelecom.fr> <997c1389-5e18-b07e-d342-c787c841a4c4@gmail.com> <711876429.20200601003941@serebryakov.spb.ru> <d67b7835-f7de-e230-08df-9d35b75b5b91@sentex.net> <a7d4eb82-29d1-34f7-85df-c6f7ffb83032@sentex.net> <CA%2Bb0zg_PVBnaOBK=Mg9923ciV0gUTZHdhiQ-oVxjJWU_dN8ANQ@mail.gmail.com> <05a17072-570a-6e05-d3e6-802b3bf30e57@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and
igb devices will use the same function instead of using two different ones
even though it seems em devices generally require the interface restart yet
igb devices do not.

The other issue is that I still don't know which devices need a restart /
which devices do not, or whether a restart is strictly necessary and if
there is another way to do this without worrying about restarting the
device.

- Eric

On Fri, Nov 6, 2020 at 3:35 PM mike tancsa <mike@sentex.net> wrote:

> On 11/6/2020 5:32 PM, Eric Joyner wrote:
> > Could you reply to that issue with what you've found?
> >
> > Though, as far as I can recall, igb(4) devices are not supposed to do
> > the iflib reset talked about in the bug, so I wouldn't expect to see a
> > link flap on those.
> >
> Hi Eric,
>
>     I have added my findings to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
> I tried it on 3 different vendor's boards. All I210 variants it seems.
>
> I am testing with
>
> --- if_em.c     2020-11-06 15:00:22.120953000 -0500
> +++ /tmp/if_em.c        2020-11-06 14:59:55.678195000 -0500
> @@ -4047,6 +4047,7 @@
>  {
>         switch (event) {
>         case IFLIB_RESTART_VLAN_CONFIG:
> +               return (false);
>         default:
>                 return (true);
>         }
>
> And if fixes the problem, but not quite sure if it introduces any
> regressions or other issues ?
>
>     ---Mike
>
>
> > - Eric
> >
> > On Fri, Nov 6, 2020 at 12:48 PM mike tancsa <mike@sentex.net
> > <mailto:mike@sentex.net>> wrote:
> >
> >     On 11/6/2020 2:17 PM, mike tancsa wrote:
> >     > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >     >> Hello Ian,
> >     >>
> >     >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >     >>
> >     >>> I noticed that my VLAN interfaces stopped working after a
> >     recent build.
> >     >>> tcpdump showed traffic leaving leaving and entering the
> >     interface but no
> >     >>> host on the network actually received any packets from this
> >     host.  A
> >     >>> binary search led me to r360902 and indeed the following
> >     change fixed
> >     >>> the issue for me:
> >     >>  Problem is, this change will return terrible situation when
> >     adding new VLAN
> >     >> will flap connection status.
> >     >>
> >     >>  It all worked before iflib: hardware VLAN filtering worked, and
> >     >> adding/removing new VLAN didn't cause link to flap.
> >     >>
> >     >>  Now, with iflib, looks like we can not have all good things at
> >     once :(
> >
> >
> >     Looks like this is captured in
> >
> >     https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> >     <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818>;
> >
> >
> >     > Hi All,
> >     >
> >     > Just came across this thread as I am running into this behaviour on
> >     > RELENG_12.  Adding a new vlan causes all vlans on the parent
> >     interface
> >     > to flap. Not the greatest thing as it bounces a LOT of traffic
> >     > potentially, flaps routing etc.  Is there a way around this ?
> >     >
> >     > This is on r367411 releng12
> >     >
> >     > igb0@pci0:2:0:0:        class=0x020000 card=0x153315d9
> >     chip=0x15338086
> >     > rev=0x03 hdr=0x00
> >     >     vendor     = 'Intel Corporation'
> >     >     device     = 'I210 Gigabit Network Connection'
> >     >     class      = network
> >     >     subclass   = ethernet
> >     >
> >     > eg. just something simple like
> >     >
> >     > ifconfig vlan16 create 10.1.2.3/29 <http://10.1.2.3/29>; vlandev
> >     igb1 vlan 16
> >     >
> >     >  # dmesg | tail -8
> >     > igb1: link state changed to DOWN
> >     > vlan16: link state changed to DOWN
> >     > vlan2049: link state changed to DOWN
> >     > vlan15: link state changed to DOWN
> >     > igb1: link state changed to UP
> >     > vlan16: link state changed to UP
> >     > vlan2049: link state changed to UP
> >     > vlan15: link state changed to UP
> >     >
> >     >
> >     >     ---Mike
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> >     mailing list
> >     > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >     <https://lists.freebsd.org/mailman/listinfo/freebsd-current>;
> >     > To unsubscribe, send any mail to
> >     "freebsd-current-unsubscribe@freebsd.org
> >     <mailto:freebsd-current-unsubscribe@freebsd.org>"
> >     >
> >     _______________________________________________
> >     freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> >     mailing list
> >     https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >     <https://lists.freebsd.org/mailman/listinfo/freebsd-current>;
> >     To unsubscribe, send any mail to
> >     "freebsd-current-unsubscribe@freebsd.org
> >     <mailto:freebsd-current-unsubscribe@freebsd.org>"
> >
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKdFRZjeY0QyE4w6D8eD0xBHJ4jX9goo5NqMpb10nFdqUh-e%2BA>