Forwarding multicast traffic between downstream interfaces

[Leonardo Brondani Schenkel]

Hello,

My understanding of RFC 4605 section 4.2 is that when there are multiple downstream interfaces, multicast traffic generated in one of the downstream interfaces should be sent to all subscribers on the other downstream interfaces. Is this the correct interpretation? Is this the behaviour I should expect from Mcproxy as well? I have configured Mcproxy in my router with the WAN as the upstream interface, and two different LANs as downstream — however, I'm using iperf to to subscribe and send multicast packets and only clients on the same LAN can see the traffic. When generating multicast traffic in the WAN, or configuring one of the LANs as upstream and the other as downstream, forwarding works as expected (upstream->downstream). I'm running tcpdump in the router and I can see that all traffic reaches the router (both IGMP and multicast), but forwarding between downstream interfaces simply does not happen.

Any clues about what I can be doing wrong?

Thanks,
Leonardo.

[Sebastian Wölke]

Hello Leonardo,

yes your interpretation of section 4.2 is correct and the proxy should work like that, but I'm not sure what could be wrong in your scenario. Can you check a few things:

1) Looks your config file similar to this?

 pinstance myProxy: WAN_interface ==> LAN1_interface LAN2_interface;

2) Is Mcproxy recognizing the subscriber:

./mcproxy -s -f <path/to/config_file>
With the paramater "-s" the proxy prints continuously the current state. Can you see the subscribed group in the output (in the expected subnet)?

3) Depends on your network configuration you need to disable the reverse path filter:

echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "0" > /proc/sys/net/ipv4/conf/<interface>/rp_filter

It sounds not like your problem but you could try it anyway.
Disable it on the subscriber interface and if nothing change additionally run Mcproxy with the parameter "-r".

4) Check error messages:

Compile Mcproxy in debug mode
and start it with ./mcproxy -sdvv -f <file>
Are there any errors in the logging files?

Kind Regards,
Sebastian

[Leonardo Brondani Schenkel]

Hi Sebastian,

Thanks for replying. I'm going to compile mcproxy in debug mode and
get back to you. In the meantime, I can confirm that:

1) the setup is pInstance myProxy: "eth0.2" ==> "br-lan" "tun0" and
I'm testing with iperf with an address of 224.0.67.67 and TTL of 5.
Mcproxy was built from the latest git source (6638aa9aab).

2) mcproxy acknowledges the subscribers on the "br-lan" and NOT on
"tun0", although I checked with tcpdump and all IGMP packets from
computers on tun0 are seen by the router (and they don't look any
different from the same packets coming from "br-lan"). In this setup,
even though a subscriber in "br-lan" is listening to the multicast
address and being recognized by mcproxy, and packets sent fron a
computer in "tun0" are seen by the router, and mcproxy lists the
correct IP as a source coming from the "tun0" interface, the listeners
in "br-lan" DO NOT receive the packets. If I restart mcproxy with a
setup of "tun0" ==> "br-lan", then in the exact same scenario the
packets from "tun0" DO get received by computers on "br-lan". I never
managed to test the opposite scenario "br-lan" ==> "tun0" since I
could not make mcproxy acknowledge the IGMP subscriptions from the
"tun0" interface and packets sent from "br-lan" are not forwarded
("correctly", since mcproxy thinks there are no subscribers on
"tun0").

3) Reverse path is disabled. I'm running mcproxy with "-r" and I
confirmed that it disabled it by itself without any action from my
part.

4) Working on that. Without debugging info, the only error I can see
is "ERROR: failed to get multicast route stats! Error: Cannot assign
requested address errno: 99" being logged every few seconds. For
reference, this is the output of "mcproxy -c":

Check the currently available kernel features.
- root privileges: Ok!

- ipv4 multicast: Ok!
- ipv4 multiple routing tables: Ok!
- ipv4 routing tables: Ok!

- ipv4 mcproxy was able to join 40+ groups successfully (no limit found)
- ipv4 mcproxy was able to set 40+ filters successfully (no limit found)

- ipv6 multicast: Ok!
ERROR: failed to set kernel table! Error: Protocol not available errno: 92
- ipv6 multiple routing tables: Failed!
- ipv6 routing tables: Ok!

- ipv6 mcproxy was able to join 40+ groups successfully (no limit found)
- ipv6 mcproxy was able to set 40+ filters successfully (no limit found)

I'm not sure if the error is related to the lack of support of "ipv6
multiple routing tables". Is that important for the operation of
mcproxy? Should I recompile the kernel as well?

If you have any other advice in the meantime, is it greatly
appreciated. Once I retest with debugging information turned on I will
post my findings.

// Leonardo.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Multicast Proxy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/multicast-proxy/YhfT0_vUH50/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> multicast-pro...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sebastian Wölke]

Hello Leonard,

eth0.2 is an virtual interface, right? The Linux mutlicast routing table don't support them. I think this is the reason of the message: ERROR: failed to get multicast route stats!.  You have to change the interface to eth0.

And I think you are using a tunnel without multicast support. You could use a GRE-tunnel (http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO/lartc.tunnel.gre.html). If you change that, mcproxy will receive the join messages.

The Error "ipv6 multiple routing tables: Failed!" is not a problem, because you don't use IPv6 and you have just on instance.


Kind regards,
     Sebastian

> multicast-proxy+unsubscribe@googlegroups.com.

[Leonardo Brondani Schenkel]

Hi again Sebastian,

No, "eth0.2" is not an alias although the naming seems to indicate so.
It's weird but it's the naming convention used by OpenWrt for the WAN
port of my router. I tried using "eth0" just in case but mcproxy would
refuse to start since "eth0" does not even have an assigned IP.

It thought as well that "tun0" was not supporting multicasting but the
interface is marked as multicast capable by "ifconfig" in both the
router and all the clients. In addition, running tcpdump in the router
attached to "tun0" shows that all packets (both IGMP and multicast
UDP) are reaching the router. Mcproxy itself receives the multicast
packets because it lists the IP coming from "tun0" as being a source.
And I tried switching to "igmpproxy" and it does see the IGMP
subscriptions from the "tun0" side. I'm not a multicast expert, but I
don't see how multicast cannot be working — any additional suggestions
about what I should look for? In any way, I'll try GRE as you
suggested because I want to find out what's going on.

I'll try the debug version of mcproxy tomorrow. I don't have access to
the machine with the cross-compiler right now.

Thanks for the help so far,
// Leonardo.

>> > multicast-pro...@googlegroups.com.

>> > For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Multicast Proxy" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/multicast-proxy/YhfT0_vUH50/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> multicast-pro...@googlegroups.com.