All of lore.kernel.org
 help / color / mirror / Atom feed
* non-OVS based vxlan config broken on 3.19-rc ?!
@ 2015-01-14 15:18 Or Gerlitz
  2015-01-14 15:52 ` thomas Graf
  0 siblings, 1 reply; 6+ messages in thread
From: Or Gerlitz @ 2015-01-14 15:18 UTC (permalink / raw)
  To: tom Herbert, thomas Graf, Marcelo Leitner, Jesse Gross; +Cc: netdev

Guys, just realized that non-OVS based vxlan config is broken with 
3.19-rc... I see that it works for me on 3.18.2 and breaks on 3.19-rc3 
(Linus tree). Tested over mlx4 (both offloaded and non offloaded modes) 
and igb, see below the simplest form I can see it breaks on 3.19-rcand 
works on 3.18

Looking on tcpdump and stats, the arp reply arrives to the 3.19-rc host 
NIC driver but is dropped along the stack beforehanded to the vxlan 
driver, not sure where and why...

Or.

> $ tcpdump -nni vxlan42 -e
> 16:48:40.961852 8e:c2:13:4f:97:6e > ff:ff:ff:ff:ff:ff, ethertype ARP 
> (0x0806), length 42: Request who-has 192.168.92.18 tell 192.168.92.17, 
> length 28
> 16:48:41.961864 8e:c2:13:4f:97:6e > ff:ff:ff:ff:ff:ff, ethertype ARP 
> (0x0806), length 42: Request who-has 192.168.92.18 tell 192.168.92.17, 
> length 28
> 16:48:42.979948 8e:c2:13:4f:97:6e > ff:ff:ff:ff:ff:ff, ethertype ARP 
> (0x0806), length 42: Request who-has 192.168.92.18 tell 192.168.92.17, 
> length 28
>
> $ tcpdump -nni eth3 -e
> 16:48:46.993870 00:02:c9:e9:bf:32 > 01:00:5e:00:00:2a, ethertype IPv4 
> (0x0800), length 92: 192.168.31.17.33434 > 239.0.0.42.4789: UDP, length 50
> 16:48:46.993905 f4:52:14:01:da:82 > 00:02:c9:e9:bf:32, ethertype IPv4 
> (0x0800), length 92: 192.168.31.18.39155 > 192.168.31.17.4789: UDP, 
> length 50
> 16:48:47.993855 00:02:c9:e9:bf:32 > 01:00:5e:00:00:2a, ethertype IPv4 
> (0x0800), length 92: 192.168.31.17.33434 > 239.0.0.42.4789: UDP, length 50
> 16:48:47.993881 f4:52:14:01:da:82 > 00:02:c9:e9:bf:32, ethertype IPv4 
> (0x0800), length 92: 192.168.31.18.39155 > 192.168.31.17.4789: UDP, 
> length 50
>
> $ nstat
> Wed Jan 14 16:54:04 2015
>
> #kernel
> IpInReceives                    2                  0.0
> IpInDelivers                    2                  0.0
> IpOutRequests                   4                  0.0
> IcmpOutErrors                   2                  0.0
> IcmpOutEchoReps                 2                  0.0
> IcmpMsgOutType8                 2                  0.0
> TcpInSegs                       1                  0.0
> TcpOutSegs                      1                  0.0
> UdpInDatagrams                  1                  0.0
> TcpExtTCPPureAcks               1                  0.0
> TcpExtTCPOrigDataSent           1                  0.0
> IpExtOutMcastPkts               1                  0.0
> IpExtInOctets                   124                0.0
> IpExtOutOctets                  670                0.0
> IpExtOutMcastOctets             78                 0.0
> IpExtInNoECTPkts                2                  0.0
>
> Every 1.0s: netstat -s -w
> Wed Jan 14 16:54:56 2015
>
> Ip:
>     1077125083 total packets received
>     182 with invalid addresses
>     0 forwarded
>     0 incoming packets discarded
>     1077124621 incoming packets delivered
>     545614475 requests sent out
> Icmp:
>     67936 ICMP messages received
>     60 input ICMP message failed.
>     ICMP input histogram:
>         destination unreachable: 3319
>         echo requests: 528
>         echo replies: 64089
>     71890 ICMP messages sent
>     0 ICMP messages failed
>     ICMP output histogram:
>         destination unreachable: 3542
>         echo request: 67821
>         echo replies: 527
> IcmpMsg:
>         InType0: 64089
>         InType3: 3319
>         InType8: 528
>         OutType0: 527
>         OutType3: 3542
>         OutType8: 67821
> UdpLite:
> IpExt:
>     InMcastPkts: 827
>     OutMcastPkts: 2993
>     InBcastPkts: 1424
>     InOctets: 2102729994314
>     OutOctets: 35397269627
>     InMcastOctets: 31854
>     OutMcastOctets: 237154
>     InBcastOctets: 453473
>     InNoECTPkts: 1440876685



# host A with IP address 192.168.31.17

IP=ip

# mlx4
ETH=eth0

$IP link del vxlan42
$IP link add vxlan42 type vxlan id 42 group 239.0.0.42 ttl 10 dstport 
4789 dev $ETH
$IP link set vxlan42 up
ifconfig vxlan42 192.168.92.17/24
ifconfig vxlan42 mtu 1450

# plain ping
ping 192.168.31.18 -c 2
# encaped  ping <-- BREAKS
ping 192.168.92.18 -c 2

# host B with IP address 192.168.31.18

IP=ip

# mlx4
ETH=eth0

$IP link del vxlan42
$IP link add vxlan42 type vxlan id 42 group 239.0.0.42 ttl 10 dstport 
4789 dev $ETH
$IP link set vxlan42 up
ifconfig vxlan42 192.168.92.18/24
ifconfig vxlan42 mtu 1450

ping 192.168.31.17 -c 2
ping 192.168.92.17 -c 2

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: non-OVS based vxlan config broken on 3.19-rc ?!
  2015-01-14 15:18 non-OVS based vxlan config broken on 3.19-rc ?! Or Gerlitz
@ 2015-01-14 15:52 ` thomas Graf
  2015-01-14 20:55   ` Or Gerlitz
  0 siblings, 1 reply; 6+ messages in thread
From: thomas Graf @ 2015-01-14 15:52 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: tom Herbert, Marcelo Leitner, Jesse Gross, netdev

On 01/14/15 at 05:18pm, Or Gerlitz wrote:
> Guys, just realized that non-OVS based vxlan config is broken with
> 3.19-rc... I see that it works for me on 3.18.2 and breaks on 3.19-rc3
> (Linus tree). Tested over mlx4 (both offloaded and non offloaded modes) and
> igb, see below the simplest form I can see it breaks on 3.19-rcand works on
> 3.18
> 
> Looking on tcpdump and stats, the arp reply arrives to the 3.19-rc host NIC
> driver but is dropped along the stack beforehanded to the vxlan driver, not
> sure where and why...

As additional data point: I tested the VXLAN-GBP with iproute2 based tunnels
on net-next and that works fine. Driver used was a e1000 in KVM.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: non-OVS based vxlan config broken on 3.19-rc ?!
  2015-01-14 15:52 ` thomas Graf
@ 2015-01-14 20:55   ` Or Gerlitz
  2015-01-15 12:20     ` Marcelo Ricardo Leitner
  0 siblings, 1 reply; 6+ messages in thread
From: Or Gerlitz @ 2015-01-14 20:55 UTC (permalink / raw)
  To: thomas Graf; +Cc: Or Gerlitz, tom Herbert, Marcelo Leitner, Jesse Gross, netdev

On Wed, Jan 14, 2015 at 5:52 PM, thomas Graf <tgraf@suug.ch> wrote:
> On 01/14/15 at 05:18pm, Or Gerlitz wrote:
>> Guys, just realized that non-OVS based vxlan config is broken with
>> 3.19-rc... I see that it works for me on 3.18.2 and breaks on 3.19-rc3
>> (Linus tree). Tested over mlx4 (both offloaded and non offloaded modes) and
>> igb, see below the simplest form I can see it breaks on 3.19-rcand works on
>> 3.18
>>
>> Looking on tcpdump and stats, the arp reply arrives to the 3.19-rc host NIC
>> driver but is dropped along the stack beforehanded to the vxlan driver, not
>> sure where and why...
>
> As additional data point: I tested the VXLAN-GBP with iproute2 based tunnels
> on net-next and that works fine. Driver used was a e1000 in KVM.


mm, so net-next.git (3.20 candidate code) and 3.18 works, but @ least
for me 3.19-rc doesn't - could you check if net.git works for you on
iproute2 based tunnels in that env? just vxlan is enough.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: non-OVS based vxlan config broken on 3.19-rc ?!
  2015-01-14 20:55   ` Or Gerlitz
@ 2015-01-15 12:20     ` Marcelo Ricardo Leitner
  2015-01-15 13:25       ` Or Gerlitz
  0 siblings, 1 reply; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-01-15 12:20 UTC (permalink / raw)
  To: Or Gerlitz, thomas Graf; +Cc: Or Gerlitz, tom Herbert, Jesse Gross, netdev

On 14-01-2015 18:55, Or Gerlitz wrote:
> On Wed, Jan 14, 2015 at 5:52 PM, thomas Graf <tgraf@suug.ch> wrote:
>> On 01/14/15 at 05:18pm, Or Gerlitz wrote:
>>> Guys, just realized that non-OVS based vxlan config is broken with
>>> 3.19-rc... I see that it works for me on 3.18.2 and breaks on 3.19-rc3
>>> (Linus tree). Tested over mlx4 (both offloaded and non offloaded modes) and
>>> igb, see below the simplest form I can see it breaks on 3.19-rcand works on
>>> 3.18
>>>
>>> Looking on tcpdump and stats, the arp reply arrives to the 3.19-rc host NIC
>>> driver but is dropped along the stack beforehanded to the vxlan driver, not
>>> sure where and why...
>>
>> As additional data point: I tested the VXLAN-GBP with iproute2 based tunnels
>> on net-next and that works fine. Driver used was a e1000 in KVM.
>
>
> mm, so net-next.git (3.20 candidate code) and 3.18 works, but @ least
> for me 3.19-rc doesn't - could you check if net.git works for you on
> iproute2 based tunnels in that env? just vxlan is enough.
>

Hi,

Just tested your commands on two virtual machines running virtio (same host), 
Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which is 3.19.0-rc4+) 
and it worked just fine for me. That is, ping went through both ways without 
issues.

I'll still try with net.git..

Did you try dropwatch? If you add a neigh entry for the remote peer and ping 
flood it, you may spot it on dropwatch.

   Marcelo

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: non-OVS based vxlan config broken on 3.19-rc ?!
  2015-01-15 12:20     ` Marcelo Ricardo Leitner
@ 2015-01-15 13:25       ` Or Gerlitz
  2015-01-15 13:31         ` Marcelo Ricardo Leitner
  0 siblings, 1 reply; 6+ messages in thread
From: Or Gerlitz @ 2015-01-15 13:25 UTC (permalink / raw)
  To: Marcelo Ricardo Leitner; +Cc: thomas Graf, tom Herbert, Jesse Gross, netdev

On 1/15/2015 2:20 PM, Marcelo Ricardo Leitner wrote:
> Just tested your commands on two virtual machines running virtio (same 
> host), Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which 
> is 3.19.0-rc4+) and it worked just fine for me. That is, ping went 
> through both ways without issues. I'll still try with net.git.. 

thanks for looking on that.

> Did you try dropwatch? If you add a neigh entry for the remote peer 
> and ping flood it, you may spot it on dropwatch. 

Will try it out, for the time being I managed to have an environment to 
test that fix I was working on recently...

Or.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: non-OVS based vxlan config broken on 3.19-rc ?!
  2015-01-15 13:25       ` Or Gerlitz
@ 2015-01-15 13:31         ` Marcelo Ricardo Leitner
  0 siblings, 0 replies; 6+ messages in thread
From: Marcelo Ricardo Leitner @ 2015-01-15 13:31 UTC (permalink / raw)
  To: Or Gerlitz; +Cc: thomas Graf, tom Herbert, Jesse Gross, netdev

On 15-01-2015 11:25, Or Gerlitz wrote:
> On 1/15/2015 2:20 PM, Marcelo Ricardo Leitner wrote:
>> Just tested your commands on two virtual machines running virtio (same
>> host), Linus' commit fb005c47f7b72edac50342b6af490af09854381b (which is
>> 3.19.0-rc4+) and it worked just fine for me. That is, ping went through both
>> ways without issues. I'll still try with net.git..
>
> thanks for looking on that.

np. Test based on 4ccce02eb31b847dd6bf8486f037ba1db39403c5 (net.git from a few 
hours..) also worked.

>> Did you try dropwatch? If you add a neigh entry for the remote peer and ping
>> flood it, you may spot it on dropwatch.
>
> Will try it out, for the time being I managed to have an environment to test
> that fix I was working on recently...

Cool

   Marcelo

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-01-15 13:40 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-14 15:18 non-OVS based vxlan config broken on 3.19-rc ?! Or Gerlitz
2015-01-14 15:52 ` thomas Graf
2015-01-14 20:55   ` Or Gerlitz
2015-01-15 12:20     ` Marcelo Ricardo Leitner
2015-01-15 13:25       ` Or Gerlitz
2015-01-15 13:31         ` Marcelo Ricardo Leitner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.