From: Bill Fink <billfink@mindspring•com>
To: Toerless Eckert <tte@cs•fau.de>
Cc: Cong Wang <cwang@twopensource•com>, netdev <netdev@vger•kernel.org>
Subject: Re: vnet problem (bug? feature?)
Date: Sat, 14 Feb 2015 13:17:44 -0500 [thread overview]
Message-ID: <20150214131744.051b90fc8dfdbf4e1bfe6bfb@mindspring.com> (raw)
In-Reply-To: <20150214101547.GA9335@faui40p.informatik.uni-erlangen.de>
On Sat, 14 Feb 2015, Toerless Eckert wrote:
> Thanks for replying, Cong.
>
> On Fri, Feb 13, 2015 at 03:48:14PM -0800, Cong Wang wrote:
> > > - Created vnet pair
> > > - NOT putting them into different namespaces.
> > > - Unicast across them works fine.
> > > - When sending IP multicsast into one end, i can not receive it on the other side
> > > (with normal socket API applications).
> >
> > Hmm, what does your routing table look like?
> >
> > They are in the same namespace, so in the same stack, so their IP addresses
> > belong to the same stack.
>
> Sure, but it must be possible to send/receive multicast packets to/from a specific
> interface. For example link-local-scope multicast. Which works.
>
> Just repeated with a mint 17, 3.13 kernel, same result:
>
> ip link add name veth1 type veth peer name veth2
> ip addr add 10.0.0.1/24 dev veth1
> ip addr add 10.0.0.2/24 dev veth2
> ip link set dev veth1 up
> ip link set dev veth2 up
Did you try disabling reverse path filtering:
echo 0 > /proc/sys/net/ipv4/conf/veth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/veth2/rp_filter
Both veth1 and veth2 are in the same subnet, but only one
(presumably veth1) is the expected source for packets coming
from net 10, so when the muticast packets from a net 10
source arrive on veth2, they are rejected for arriving
on the wrong interface.
You could check this with "nstat -z | grep -i filter".
The above is an educated guess on my part, and could
be something completely different.
-Bill
> Receiver socket, eg: on veth2:
> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
> setsockopt(SO_REUSEADDR, 1)
> bind(0.0.0.0/<port>)
> setsockopt(IP_ADD_MEMBERSHIP, 224.0.0.33/10.0.0.2)
>
> check wih "netstat -gn" that there is IGMP membership on veth2:
> veth2 1 224.0.0.33
>
> Sender socket, eg: on veth1:
> socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
> setsockopt(SO_REUSEADDR, 1)
> bind(10.0.0.1/7000)
> connect(224.0.0.33/<port>)
>
> Sending packet, check how they're transmitted:
> - TX countes on veth1 go up (ifconfig output)
> - RX counters on veth2 go up (ifconfig output)
> - tcpdump -i veth2 -P in shows packets being received
> - tcpdump -i veth1 -P out shows packets being sent
>
> Played around with lots of parameters:
> - same behavior for non-link-local-scope multicast, TTL > 1 doesn't elp.
> - same behavior if setting "multicast, "allmulticast", "promiscuous" on the veth
> - same behavior when setting IP_MULTICAST_LOOP on sender.
>
> Routing table:
> netstat -r -n
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth1
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 veth1
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 veth2
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
>
> And of course it works if one side is put into a separate namespace,
> but that doesn't help me.
>
> But: it really seems to be a problem with the kernel/sockets, not with veth.
> Just replaced the veth pair with a pair of ethernets with a loopback cable and
> pretty much exactly the same result (except that receiver side does not see
> packets in RX unless it's promiscuous or has a real receiver socket, but that's
> perfect). But not being a veth problem but other kernel network stack "feature"
> doesn't make it right IMHO. I can't see by which "logic" the receiver socket
> seemingly does not care about these packets even though it's explicitly bound
> to the interface and the multicast group. "Gimme the darn packets, socket,
> they are received on the interface"! ;-))
>
> I can play around with the receiver side socket API call details, but i really
> don't see why those should be different if the packets happen to be looped
> than if they're not.
>
> Cheers
> Toerless
next prev parent reply other threads:[~2015-02-14 18:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-13 11:41 vnet problem (bug? feature?) Toerless Eckert
2015-02-13 23:48 ` Cong Wang
2015-02-14 10:15 ` Toerless Eckert
2015-02-14 18:17 ` Bill Fink [this message]
2015-02-15 10:12 ` Toerless Eckert
2015-02-15 19:00 ` Toerless Eckert
2015-02-15 21:16 ` Sowmini Varadhan
2015-02-16 10:13 ` Toerless Eckert
2015-02-16 15:30 ` David Ahern
2015-02-16 19:54 ` David Miller
2015-02-16 21:51 ` Bill Fink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150214131744.051b90fc8dfdbf4e1bfe6bfb@mindspring.com \
--to=billfink@mindspring$(echo .)com \
--cc=cwang@twopensource$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=tte@cs$(echo .)fau.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox