From: Mark Tomlinson <hidden> Date: 2016-09-22 04:13:45
The previous patch to ensure that the original iif was used when
checking for forwarding also meant that this same interface was used to
determine whether multicast packets should be received or not. This was
incorrect, and would cause multicast packets to be dropped.
The fix here is to use skb->dev when checking multicast addresses.
skb->dev has been set to the l3mdev by this point, so the check will be
against that, rather than the ingress interface.
Fixes: "net:VRF: Pass original iif to ip_route_input()"
Signed-off-by: Mark Tomlinson <redacted>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: David Ahern <hidden> Date: 2016-09-22 15:14:49
On 9/21/16 10:13 PM, Mark Tomlinson wrote:
The previous patch to ensure that the original iif was used when
checking for forwarding also meant that this same interface was used to
determine whether multicast packets should be received or not. This was
incorrect, and would cause multicast packets to be dropped.
The fix here is to use skb->dev when checking multicast addresses.
skb->dev has been set to the l3mdev by this point, so the check will be
against that, rather than the ingress interface.
l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
What test are you running that says your previous patch broke something?
From: Mark Tomlinson <hidden> Date: 2016-09-22 22:10:40
On 09/23/2016 03:14 AM, David Ahern wrote:
l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
What test are you running that says your previous patch broke something?
Although we do not expect any multicast routing to work in an l3mdev,
(IGMP snooping or PIM), we still want to have multicast packets
delivered for protocols such as RIP. This was working before my previous
patch, but these multicast packets are now dropped. This current patch
fixes that again, hopefully still with the benefits of my first patch.
From: David Ahern <hidden> Date: 2016-09-22 22:41:03
On 9/22/16 4:10 PM, Mark Tomlinson wrote:
On 09/23/2016 03:14 AM, David Ahern wrote:
quoted
l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
What test are you running that says your previous patch broke something?
Although we do not expect any multicast routing to work in an l3mdev,
(IGMP snooping or PIM), we still want to have multicast packets
delivered for protocols such as RIP. This was working before my previous
patch, but these multicast packets are now dropped. This current patch
fixes that again, hopefully still with the benefits of my first patch.
can you discern which check is making that happen?
It does not make sense to look at the in_device of a vrf device for mcast addresses. For IPv6 linklocal and mcast is specifically blocked. IPv4 should do the same. So, how is RIP getting the packet at all?
From: Mark Tomlinson <hidden> Date: 2016-09-23 03:06:48
On 09/23/2016 10:41 AM, David Ahern wrote:
On 9/22/16 4:10 PM, Mark Tomlinson wrote:
quoted
On 09/23/2016 03:14 AM, David Ahern wrote:
quoted
l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
What test are you running that says your previous patch broke something?
Although we do not expect any multicast routing to work in an l3mdev,
(IGMP snooping or PIM), we still want to have multicast packets
delivered for protocols such as RIP. This was working before my previous
patch, but these multicast packets are now dropped. This current patch
fixes that again, hopefully still with the benefits of my first patch.
can you discern which check is making that happen?
It does not make sense to look at the in_device of a vrf device for mcast addresses. For IPv6 linklocal and mcast is specifically blocked. IPv4 should do the same. So, how is RIP getting the packet at all?
This might be due to some other changes we've made for VRF and multicast
but haven't sent upstream. In particular, a change to do_ip_setsockopt()
and its handling of IP_MULTICAST_IF as well as IP_ADD/DROP_MEMBERSHIP. I
am guessing that without these changes, we wouldn't be able to receive
multicast packets in RIP. With our changes, the in_dev->mc_list does
contain the RIP MC address (224.0.0.9) in the master interface, and so
the function ip_check_mc_rcu() returns success with the master only.
Our RIP daemon is VRF-aware. So it does use setsockopt(SO_BINDTODEVICE,
"vrf-master") when running in a VRF. Without following it all the way
down, I believe that it is this that allows the multicast lookup at the
top of ip_check_mc_rcu() to succeed on the vrf-master, but not the
ingress interface. That is, in_dev->mc_list does contain 224.0.0.9 only
on the vrf-master. Provided the lookup in ip_check_mc_rcu() succeeds (im
!= NULL), this function can return success.
Are you interested in the other patches at the moment?
From: David Ahern <hidden> Date: 2016-09-23 13:49:45
On 9/22/16 9:06 PM, Mark Tomlinson wrote:
On 09/23/2016 10:41 AM, David Ahern wrote:
quoted
On 9/22/16 4:10 PM, Mark Tomlinson wrote:
quoted
On 09/23/2016 03:14 AM, David Ahern wrote:
quoted
l3mdev devices do not support IPv4 multicast so checking mcast against that device should not be working at all. For that reason I was fine with the change in the previous patch. ie., you want the real ingress device there not the vrf device.
What test are you running that says your previous patch broke something?
Although we do not expect any multicast routing to work in an l3mdev,
(IGMP snooping or PIM), we still want to have multicast packets
delivered for protocols such as RIP. This was working before my previous
patch, but these multicast packets are now dropped. This current patch
fixes that again, hopefully still with the benefits of my first patch.
can you discern which check is making that happen?
It does not make sense to look at the in_device of a vrf device for mcast addresses. For IPv6 linklocal and mcast is specifically blocked. IPv4 should do the same. So, how is RIP getting the packet at all?
This might be due to some other changes we've made for VRF and multicast
but haven't sent upstream. In particular, a change to do_ip_setsockopt()
and its handling of IP_MULTICAST_IF as well as IP_ADD/DROP_MEMBERSHIP. I
am guessing that without these changes, we wouldn't be able to receive
multicast packets in RIP. With our changes, the in_dev->mc_list does
contain the RIP MC address (224.0.0.9) in the master interface, and so
the function ip_check_mc_rcu() returns success with the master only.
Our RIP daemon is VRF-aware. So it does use setsockopt(SO_BINDTODEVICE,
"vrf-master") when running in a VRF. Without following it all the way
down, I believe that it is this that allows the multicast lookup at the
top of ip_check_mc_rcu() to succeed on the vrf-master, but not the
ingress interface. That is, in_dev->mc_list does contain 224.0.0.9 only
on the vrf-master. Provided the lookup in ip_check_mc_rcu() succeeds (im
!= NULL), this function can return success.
Are you interested in the other patches at the moment?
Yes, but with the context of the bigger IPv4 multicast solution. I am on PTO today - about to get on a plane. How about we leave the upstream kernel as is - i.e., drop this patch. You can carry it locally with the others. We can take a look at the bigger mcast picture for 4.10. Agree?