-
-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multicast via OpenVPN tunnel #77
Comments
Hi @jbysewski, awesome report, and I'm happy to see someone using my little Now, PIM, unlike DVMRP (mrouted), does not flood multicast to all routers. So C2 needs to run For PIM to work, there needs to be a unicast routing table setup first. This can be done with RIP, OSPF, or static unicast routes. That's where the protocol independent in PIM comes from. Easily tested by checking that C1 can ping C2 and vice versa. Very observant of you to notice you need to change the TTL, that's usually FAQ n:o 1. In the |
It seems I had a pimd running on C1. I redid the experiment with a bit different results, but I don't understand why it's different now (but I restarted the GSM routers).
I suppose that the three instances of pimd see each other as neighbors is a good thing.
Could that be a hint? Currently I fail to understand what else to do. |
First thing to test, whatever you do, make unicast ping between C1 and C2 work. Without that, you're toast. Second, start mcjoin on C2 so the nearest router understands it needs to request multicast. |
Did you give up, or get it working? |
None of the above. :-) |
I see! 😃 That's great news, take care of your family and we'll pick this one up when time permits again. Cheers! |
Anyone can point to a guide - if I see multicasts from needed devices on each of the interfaces eth0 and tap0 of the same host, but can't forward one from tap0 to eth0. What would be the correct steps? |
@Voronenko use tcpdump or Wireshark to verify the TTL in the IP header of the multicast traffic. It must be > 1 for the traffic to be forwarded from one interface to another. Then check the IP forwarding setting of the kernel, on each of the involved interfaces. |
@Voronenko maybe, also check that the MTU on both interfaces is large enough to convey the packets. It looks like tap0 is a tunnel, which usually shrinks the MTU. (though it seems that your data flows in the direction of smaller mtu to larger mtu) |
@troglobit @jp-t Thank you all for a response. I suspect it is oftopic, but perhaps can be converted to some example. So: I tried to affect TTL in a following manner - either increase TTL by 2 when goes to needed destination
as well as hardcore abnormal TTL 128 or 255
So right now TTLs are quite high - but I see notifications only from local devices on each network respectively:
Re forwarding:
Re "on each of the involved interfaces": Do you mean kind of
(note: not sure if masquerade is needed)
Should I tune pimd.conf from defaults? |
The 224.0.0.* is link-local only, and should never be routed. I'd recommend bridging networks instead if that is what you want. (This is a very common question actually, which never ends well for those attempting to route it. Also very probably why the TTL is 1) |
For notes of everyone interested, who would came here.
POC - both multicasts on single interface
Now , if eth0 is in the same network as br0, it most likely will get another address, |
Hi troglobit,
I have the following situation where I'm attempting to get multicast traffic from Client1 to Client2 (or any other client in their respective subnets).
I run pimd in default configuration on Router1, Server and Router2 but it seems I can't get multicast traffic from Client1 beyond Router1.
Preparation
Also tried the following on R1 and S:
Test 1 - ping
Test 2 - mcjoin
But if we start mcjoin as a sender on R1 the multicast traffic from C1 starts to come through - but only while R1 is also sending.
I could do multicast iperf from R1 -> S or from C1 -> R1 but not get it from C1 -> S.
Additional info
I have tried the same configuration with OpenVPN configured to tun-networking.
Any help would be much appreciated.
The text was updated successfully, but these errors were encountered: