vxlan(4) regression

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

vxlan(4) regression

Michael Graves
Hello

I think I have found a possible regression introduced in if_bridge.c at
version
1.323.

Using the following setup

C1 ----------------- R1 ---------------------+
       (em1 - bridge0 - vxlan0 - em0 )        |
                                             LAN
                                              |
C2 ----------------- R2 ---------------------+
       (em1 - bridge0 - vxlan0 - em0 )

See https://marc.info/?l=openbsd-misc&m=156261409204575&w=2 for dmesg
and
hostname.* information.

C1 and C2 are connected to R1 and R2.  Both R1 and R2 and OpenBSD 6.5.
vxlan0 on R1 and R2 is configured with a multicast destination address.
When
C1 tries to ping C2 the ping succeeds however the encapsulated packet is
sent
to the multicast address address and not directly from R1 to R2.

Trying to trace the problem down I think the issue is related to when
the mbuf
is passing thru bridgeintr_frame() it is not getting tagged as tunneled
traffic, thus the tunnel information stored in the bridge is not
updating the
destination address when the mbuf is processed by vxlan_output().

The diff below seems to correct this issue and was taken from the 6.5
source.  I am not sure it is the correct way to solve the issue.  If
there is
better way to solve the issue I'm happy to assist and/or test.  If I'm
on the
right track, I'm happy to submit a patch against 6.5-current.

Thanks for your response.
Kind regards.

--- if_bridge.c.orig    Sun Mar 31 08:59:38 2019
+++ if_bridge.c Tue Jul 16 10:14:29 2019
@@ -905,7 +905,7 @@
          * side of the bridge, drop it.
          */
         if (!ETHER_IS_MULTICAST(eh.ether_dhost)) {
-               dst_if = bridge_rtlookup(sc, dst, NULL);
+               dst_if = bridge_rtlookup(sc, dst, m);
                 if (dst_if == src_if) {
                         m_freem(m);
                         return;

Reply | Threaded
Open this post in threaded view
|

Re: vxlan(4) regression

Martin Pieuchot

Hello Michael,

On 17/07/19(Wed) 08:59, Michael Graves wrote:
> I think I have found a possible regression introduced in if_bridge.c at
> version 1.323.

So the bug is not present at revision 1.322?

> Using the following setup
>
> C1 ----------------- R1 ---------------------+
>       (em1 - bridge0 - vxlan0 - em0 )        |
>                                             LAN
>                                              |
> C2 ----------------- R2 ---------------------+
>       (em1 - bridge0 - vxlan0 - em0 )
>
> See https://marc.info/?l=openbsd-misc&m=156261409204575&w=2 for dmesg and
> hostname.* information.
>
> C1 and C2 are connected to R1 and R2.  Both R1 and R2 and OpenBSD 6.5.
> vxlan0 on R1 and R2 is configured with a multicast destination address. When
> C1 tries to ping C2 the ping succeeds however the encapsulated packet is
> sent
> to the multicast address address and not directly from R1 to R2.
>
> Trying to trace the problem down I think the issue is related to when the
> mbuf
> is passing thru bridgeintr_frame() it is not getting tagged as tunneled
> traffic, thus the tunnel information stored in the bridge is not updating
> the
> destination address when the mbuf is processed by vxlan_output().

I understand your analysis.  What I find strange is that
bridge_copytag() wasn't call previously in bridgeintr_frame().  So I
don't understand which issue/regression we are fixing.  Do you?

>
> The diff below seems to correct this issue and was taken from the 6.5
> source.  I am not sure it is the correct way to solve the issue.  If there
> is
> better way to solve the issue I'm happy to assist and/or test.  If I'm on
> the
> right track, I'm happy to submit a patch against 6.5-current.

A diff against current would definitively help.

> --- if_bridge.c.orig    Sun Mar 31 08:59:38 2019
> +++ if_bridge.c Tue Jul 16 10:14:29 2019
> @@ -905,7 +905,7 @@
>          * side of the bridge, drop it.
>          */
>         if (!ETHER_IS_MULTICAST(eh.ether_dhost)) {
> -               dst_if = bridge_rtlookup(sc, dst, NULL);
> +               dst_if = bridge_rtlookup(sc, dst, m);
>                 if (dst_if == src_if) {
>                         m_freem(m);
>                         return;
>

Reply | Threaded
Open this post in threaded view
|

Re: vxlan(4) regression

Michael Graves
On 2019-07-17 11:41, Martin Pieuchot wrote:
> Hello Michael,
>
> On 17/07/19(Wed) 08:59, Michael Graves wrote:
>> I think I have found a possible regression introduced in if_bridge.c
>> at
>> version 1.323.
>
> So the bug is not present at revision 1.322?
>
I still have the problem with revision 1.322 so I obviously was
mistaking.

I'll continue to try and figure out where the issue might have started.

Thanks for the response, sorry for the noise.