<div dir="ltr">hi,<div><br></div><div>Thanks a lot, Werner.</div><div><br></div><div>The userspace multicast routing daemon (pimd) was exactly what I wanted. I am able route multicast between pc2 and pc3 with it running.</div>
<div><br></div><div>I did not have a specific requirement of routing only multicast packets. So normal routing table entries were enough.</div><div><br></div><div>Ya, this setup was related to my previous mail on VPN. This was to make a way so that I need to make only one single tunnel between a server and client using openvpn, and still be able to do ip-multicast between any machines that were connected to the tunneling (the client and server of vpn of each sides) machines using the common tunnel instead of each client having a tunnel to server. This would make the whole vpn setup transparent to the end machines and still be able to do ip-multicast.</div>
<div><br></div><div>I hope this is one of the "right" solutions. I would certainly like suggestions if this is not one of the best ways.</div><div><br></div><div>-Nazeem</div><div><br><div class="gmail_quote">On Sun, Feb 14, 2010 at 3:29 AM, Werner Schram <span dir="ltr"><<a href="mailto:wrschram@gmail.com">wrschram@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">On Sat, Feb 13, 2010 at 12:26 PM, Nazeem نجم لدين <<a href="mailto:nazeemnss@gmail.com">nazeemnss@gmail.com</a>> wrote:<br>
> hi,<br>
><br>
> Consider 3 pc's,<br>
><br>
> pc1: Has two 2 NIC's , eth0 (<a href="http://10.100.0.1/16" target="_blank">10.100.0.1/16</a>) and eth1 (<a href="http://10.200.0.1/16" target="_blank">10.200.0.1/16</a>).<br>
> pc2: eth0 (10.100.0.2), connected to eth0 of pc1 and has default gateway<br>
> 10.100.0.1<br>
> pc3: eth0 (10.200.0.2), connected to eth1 of pc1 and has default gateway<br>
> 10.200.0.1<br>
><br>
> ie,<br>
> we have two subnets.<br>
><br>
> 10.100.0.2 [eth0] ---------- [eth0] 10.100.0.1 | 10.200.0.1<br>
> [eth1]------------ [eth0]10.200.0.2<br>
> pc2 pc1<br>
> pc3<br>
><br>
> Now how do I route multicast packets, so that I can ip-multicast from pc2 to<br>
> pc3 or vice-versa?<br>
> The problem is that if trying to add route on pc 1, 224/4 has to be routed<br>
> to both eth0 and eth1 depending upon from whether they come from pc2 or pc3.<br>
<br>
</div></div>I havent done to much with multicast, but maybe I can help you to get<br>
on your way. You noted that it is imposible to define a route in your<br>
routing table, which is correct. Multicast routing is a kind of<br>
anomally (in respect to common unicast traffic) which is handled by a<br>
userspace daemon on linux (take a look at pimd).<br>
<br>
The userspace daemon keeps track of the hosts that are subscribed to<br>
the multicast traffic, and routes the traffic accordingly.<br>
Subscriptions are handled using the IGMP protocol (so you should allow<br>
IGMP traffic in your firewalls and ACLs). If you have a host that<br>
sends multicast, it should route it to a host that can handle<br>
multicast subscriptions.<br>
<br>
So in your situation, you should run a multicast daemon on pc1 (pimd<br>
for example). I suspect this is related to the VPN setup from your<br>
earlier mail? If this is the case, do you only want multicast traffic<br>
to go trough the vpn, or all traffic? The first case might be a bit<br>
hard to setup so it might be easier to start with routing all traffic<br>
trough the VPN and then work to splitting off the normal traffic. To<br>
get multicast working, you should setup your hosts (pc2 and pc3) to<br>
route 224/4 to the server running the multicast daemon (pc1). You can<br>
do this by using static routes or by changing your dhcp configuration.<br>
If you route all traffic (so unicast and multicast) to pc1, you will<br>
have the default gateway set to pc1, in which case you shouldn't<br>
change anything.<br>
<br>
Note that errors are presented using the ICMP protocol, so if things<br>
don't work as expected, it might be a good idea to use wireshark or<br>
tcpdump to monitor those packets.<br>
<br>
This page has a pretty good explanation about what goes in in<br>
multicast (although section 2.3 doesn't explain the IGMP subscription<br>
mechanism, which I find slightly confusing):<br>
<a href="http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Multicast-HOWTO.html" target="_blank">http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Multicast-HOWTO.html</a><br>
<br>
I hope this helps.<br>
<br>
Regards,<br>
<font color="#888888">Werner<br>
</font><div><div></div><div class="h5"><br>
--<br>
ubuntu-users mailing list<br>
<a href="mailto:ubuntu-users@lists.ubuntu.com">ubuntu-users@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-users" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>لا اله الا الله محمد رسول الله<br>
</div></div>