lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Sat, 24 Nov 2012 01:24:42 +0000 (UTC)
From:	Bernhard Schmidt <>
Subject: Re: VXLAN multicast receive not working

Bernhard Schmidt <> wrote:

>>> The same VXLAN domain is defined on the Nexus 1000V and a VM is attached
>>> to it. When I send some broadcast traffic down vxlan0 (i.e. ping
>>> which generates an ARP request) the VM sees the packet just
>>> fine.
>>> When I do it the other way around (the VM sends a broadcast ARP for
>>> I see a packet coming into eth1 on the multicast group, but
>>> vxlan0 stays silent. 
>> I think I found a possible reason, my vxlan interface is on top of eth1
>> 7: vxlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue
>> state UNKNOWN mode DEFAULT 
>>     link/ether 96:06:c6:cf:a0:2e brd ff:ff:ff:ff:ff:ff
>>     vxlan id 12340 group dev eth1 port 32768 61000 ageing 300 
>> but the multicast group is joined only on eth0
> Confirmed working as soon as eth0 can receive the group multicast
> address (connected to the same VLAN), even if the vxlan0 interface is
> still configured to eth1.

When swapping the configuration around using eth0 for the VXLAN
transport and eth1 for Management, the group is joined on eth1. It is
always joined where the default route points, so it looks like the
interface is not set at all.

# ip route add <group>/32 dev <vxlanintf>

works around the problem.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists