Hello,
I have a server that sits between two LANs, and I wish to forward multicast traffic from one LAN to the other. I have multicast routing enabled in the kernel, and mrouted running, and if I watch /proc/net/ip_mr_cache, I can see it working properly. However, the traffic just simply doesn't get forwarded. These are the steps I am taking to troubleshoot the problem:
1. Launch VLC on a workstation on LAN A, and start multicast-streaming a video.
2. Examine ip_mr_cache on the server. I see the group show up in ip_mr_cache, with a proper Iif entry showing the interface connected to LAN A. The Oif column is blank.
3. Launch VLC on a workstation on LAN B, and try to connect to the multicast on the same group address.
4. Examine ip_mr_cache on the server. I now see an entry show up in the Oif column for the multicast group in question.
5. Check tcpdump on both interfaces on the server. Packets are not forwarding.
So, correct me if I'm wrong, but it seems that mrouted detects the multicast ok on LAN A, and also the receiver joining the group on LAN B. It seems to be properly configuring the multicast route in the kernel also. Running a tcpdump on the LAN A interface on the kernel shows a massive packet storm from the multicast stream. But running the same tcpdump on the LAN B interface shows that nothing is being forwarded. Also, the LAN B client doesn't start showing the video.
Oh, also, this server forwards unicast just fine. Is there a file like /proc/sys/net/ipv4/ip_forward that must be accessed to enable multicast forwarding? As far as I can tell it is all ready to go - the packets just aren't being forwarded.
Thanks for listening.
| Linux Bootup hangs after adding RealTime Premption and HR-Timer | 47 minutes ago | Linux kernel |
| SATA 2 size problems | 1 hour ago | Windows |
| problem with 2.6 kernel driver for a USB MAG Stripe Reader as HID device. | 14 hours ago | Linux kernel |
| get_user_pages failure | 15 hours ago | Linux kernel |
| Reading linux kernel | 17 hours ago | Linux kernel |
| High level of Seagate 2.5" SATA drives failing | 23 hours ago | Hardware |
| Resetting the bios password for Toshiba Laptop | 1 day ago | Hardware |
| Linux 2.6.22 slowly RUNS OUT OF LOWMEM | 1 day ago | Linux kernel |
| Questions about modules | 1 day ago | Linux kernel |
| KDB | 2 days ago | Linux kernel |
Further Info
As everywhere, it seems very difficult to elicit so much as a single response on the topic of multicasting. Is no one doing it at all? I notice the multicasting.txt file in the kernel Documentation/networking directory is ancient, listing the capabilities of NICs that are probably best seen in museums these days.
Is multicasting support quietly disappearing from Linux?
in my class of networking lab
in my class of networking lab, two teams were working on mulicast project namely LSM and PGM , neither of those teams could get multicast at all, nothing worked. all mroute,pgmd,sroute failed. Any could provide a latest and comprenhensive guide it would be great.
Doubts
1) Multicast (for TCP) is hardly ever used...
2) Try 2.4 Kernels (please look if you've included the multicast support)
3) Check your switch... does it support multicast?
4) Forget about Multicast TCP and use UDP's Broadcast feature!
All too common
It's the same everywhere I look. On the Gentoo, quagga, and openvpn forums there are very similar questions to yours and mine. There also seems to be a similar one on even the linux net-devs list on vger dated January 17. In all cases, no response whatsoever. At what point can we raise the flag that maybe multicast routing is really broken in the 2.6 kernel?
I'm in the middle of setting up a test linux router with interchangeable 2.4 and 2.6 kernels to see if the this can be demonstrated in any meaningful way. Is this one to bring to the linux-kernel list?
It seems multicast on ip need
It seems multicast on ip needs the multicast router and igmp, the kernel multicast options just means the multicast forwarding is turn on, but you the forwarding needs more conditions...
Exactly
Yes, and if you re-read the original post, you will see that I have both active. The kernel supports multicast routing, and there is a routing protocol program running.
In a way, its very similar to unicast routing. You have some program which, either automatically (quagga) or statically (route or ip) sets routes in the kernel routing table. As long as ip routing is enabled in the kernel, and it is specifically activated in the running system, the kernel just forwards the packets based on the routes it finds in the routing table.
For multicast, it seems to be the same. You can automatically (mrouted or pimsm) or statically (smcroute) add multicast routes into the table. The table is easily viewed by looking at the contents of /proc/net/ip_mr_cache. As long as the kernel has multicast routing enabled, and you have it activated at run-time, it should just forward the multicasts, right?
Only thing: It doesn't. At least 2.6.16.9 doesn't. If you do a search of several networking, routing, and linux forums, you'll see that I'm not the only one with this problem.
I have raised these questions
I have raised these questions quite few places, but no answer. And I have tried working with 2.6.15 kernel. no hope. We tried every single thing.
Remember that you must have
Remember that you must have a route to 224.0.0.0 pointing via the eth device on which you want to receive multicast.
Have you checked that the LAN
Have you checked that the LAN switches have multicast filtering on/off?
Have you checked the multicast packet rates on the two interfaces on the router? Are you seeing the frames being received at the router? Is the router broadcasting IGMP query updates?
Multicast routing and forwarding is a hideously complex subject. Check out the RFCs on IGMP and PIM for an idea of what's going on here.
Sadly, quite possibly.
The IGMP definitions are poorly maintained, it's unclear whether the IGMPv3 implementation for Linux is really present (or only partial), and there are numerous quirks (you cannot both forward and receive multicast).
If you are using PIMv2 multicast, I would suggest trying pimd - it's a fairly old Linux multicast router (it's listed on Freshmeat) but it is better than others I've tried. Do NOT use Mrouted under ANY circumstance known to mankind. Mrouted is based on DVMRP, which is an arcane, inefficient and problematic protocol. Worse, Mrouted became abandonware a LONG time ago - pimd may be old, but it is much newer.
Make sure that all end-points have multicasting enabled and have static routes enabled for multicast groups. I never did finish what I started in the Linux advanced routing guide, but it's good enough for this. This is necessary as multicast traffic will not be forwarded down links that don't request that multicast traffic.
Multicast traffic can be problematic when sending and receiving via the same interface, even when forwarded to different devices. Never figured out why, but most software routers supporting multicast won't enable multicast forwarding when using a single device. It seems to be assumed that if multiple routers are on the same segment, they can all see the same multicast streams (even if they can't).
Personally, I think the entire multicast module needs to be ripped out and re-written. I have thought this for some considerable time. If someone can build me a time machine so I can get the time to do it, I would do exactly that - get the whole thing written, clean, fully RFC-compliant, compliant with the full list of multicast-related RFCs, up-to-standard and up-to-date.
Possible answer from other forum topic?
From http://kerneltrap.org/node/8157
You should check that the TTL
You should check that the TTL of the multicast packets transmitted by the sender are larger than 1. As mrouted sets up your kernel to route the multicast frames, you need them to be larger than 1. Otherwise the frames will only be discarded. VLC should have an option to set the ttl of multicast frames sent. This is a very common issue with multicasting.
Also UDP should be the protocol of choice for multicasting. In the past I have tested multicast with VLC without any problems. I haven't got access to a vlc right now. So I can't verify.
Another thing to check: multicast groups should be addresses between 224.0.1.0 and 239.255.255.255 But since you see the multicast routing tables populated, I guess you already know this.
Regards,
Jan
Yes, yes, yes, yes, and ... no.
In answer to the above two:
My LAN switch is a simple dumb switch. When you multicast on it, it simply sends it to every port like a broadcast. A tcpdump on the router shows a storm of frames from the VLC multicaster, and the packet and byte count in /proc/net/ip_mc_cache is incrementing properly. If I put 5 computers on the first LAN, they all receive the video no problem. Yes, it's UDP multicast, and I tried TTL's from 3 all the way up to 64 to see if I could get it to forward through the Linux router. I chose the destination group of 238.2.2.2 which easily falls within the multicast range.
It just won't forward.
To verify my VLC multicasts were set up correctly on both ends I plugged a Cisco PIX into both LANs and set up multicast forwarding, and it forwards just fine - it just can't keep up to the load.
mrouted should enable multica
mrouted should enable multicast forwarding when it loads.
You can verify this by executing:
"more /proc/sys/net/ipv4/conf/eth*/mc_forwarding"
For both network interfaces of the server you should see a "1".
Other recommendations that I can give you:
- make sure any firewall is disabled on your client and server.
- try another version of mrouted.
This is what I set in my mrouted.conf file:
phyint eth2 force_leaf
phyint eth0 force_leaf
Force_leaf wil force mrouted to not try to connect to other multicast routers on those interfaces. I am not sure this should help, but you can try anyway.
For further troubleshooting we would need more details.
The output of:
cat /proc/net/ip_mr_vif
cat /proc/net/ip_mr_cache
cat /proc/net/igmp
output of "mrouted -d" while the client on the remote subnet joins.
smcroute works on kernel 2.6-9
I haven't had any luck with mrouted whenever
I've tried it.
But I have been able to get smcroute forwarding
on Fedora Core 3, which uses kernel 2.6-9.
Also works fine on 2.4 kernels.
To verify the multicast route addresses and interfaces
are set up correctly, run: ip mroute show
multicast forwarding works on kernel 2.6.16
I can confirm that multicast forwarding works
fine on kernel 2.6.16, using FC5. I have it
working with both mrouted and smcroute.
I'm not doing anything unusual to get it to work.
I don't know why any of you are having problems,
sounds like you're doing what you're supposed to.
Definitely should re-confirm the TTL setting is not
too small, because this will result in the behavior
you are describing. Use tcpdump/ethereal to verify
the TTL is really high enough.
Since my previous posting, I tried looking at
mrouted again and figured out how to make it work.
One thing to check on with mrouted is to
make sure the Makefile is set up appropriately
for Linux, as there are some defines that must
be used on Linux. That was one of the things
that was causing it to fail for me, although I
don't think that is your problem.
Several little
Several little questions......
What is your mrouted version?
and your config file (mrouted.conf)?
How many eth_ are you used? It´s possible with only one interface?
Thanks thanks thanks!!!
annoying
I have had the same problem on a linux router with Kernel version 2.6.11, mrouted installed and running and a route for all multicast groups to all interfaces (like route add -net 224.0.0.0 mask 240.0.0.0 gw xx.xx.xx.xx (also to an interface)), multicast isn't working for me in this configuration.
After removing all routes for multicast (shown in route -n) multicast session working quite well with mrouted, also the multicast stream via vlc into different physical networks!
Ah! Ok, I will try this.
Ah! Ok, I will try this.
Although even if it works, it still isn't a good thing. I have a couple services that rely on that 240.0.0.0 route that will have to be disabled to get multicast routing to work.
Wouldn't this constitute a serious bug? It really seems like no one cares to work in this part of the Linux network stack.
Try vlc console..
I don know if it will help you, but when I use VLC to multicast-streaming using tu GUI interface it doesn`t work..It seems that its all ok, but doesn`t work. So I stream unsing console with
vlc -vvv Filmes/low-fico.cd1.avi :file-caching=300 --sout udp:239.255.12.43 --ttl 12
and then it works...
Hello fellow multicasters,
Hello fellow multicasters,
I have a few questions not about Multicast Forwarding, but more on general IGMP in Linux. Since this thread is well and active, I thought I might just post my questions here:
1) I'm currently joining and receiving multicast traffic on a datagram socket (UDP). I know theoretically multicast traffic can be sent over any transport protocol or even as the IP payload. How can I accommodate this? Will using a raw socket work? What about the IP address and port# I bind to?
2) If a socket has joined a group and while receiving traffic the socket closes, what happens to the subscribed group in the kernel? Looking at /proc/net/igmp, it seems all subscribed groups also disappears (which is what I want).
3) I have two network interface cards that join the same group (on different subnets), they are both listening to UDP 230.0.0.1:9000. When one interface starts receiving traffic, the kernel sends the packets up to both sockets, how do I prevent this? I want the kernel to only send packets to the one socket subscribed on that interface.
4) Has anyone tried to patch a 2.4 kernel for IGMPv3 support using:
http://www.cesnet.cz/tf-ngn/multicast/ssm/linux-igmpv3.html
Any comments or problems?
I know these are detailed questions, so any help is really appreciated, thanks!
try -allmulti
For 3, just a guess, but try:
ifconfig __interface__ -allmulti
Not sure about your other queries.
Tried ALLMULTI - no change.
Tried ALLMULTI - no change. The routes show up just fine where they should be, in the /proc/net/ip_mr_cache et al files. But the packets just won't forward. :-(
Just to be sure about the TTL I see everyone mentioning, I set my TTL to 64. Still nothing.
By the way, here's the relevant line in my /proc/net/ip_mr_cache file:
1. After starting a stream on the multicast sender (vlc):
-----------------------------------------------------
Group Origin Iif Pkts Bytes Wrong Oifs
020202EE 122C11AC 2 11612 15606528 0
-----------------------------------------------------
2. After starting vlc and trying to connect to the multicast stream
-----------------------------------------------------
Group Origin Iif Pkts Bytes Wrong Oifs
020202EE 122C11AC 2 12072 16224768 0 0:1
-----------------------------------------------------
You can see from item 1 above, that the multicast stream is coming in on eth2 (the Iif column) but that there is no reason to route it (blank under Oifs). But in item 2 above, after I have started the listener, you can see that there is now an entry under Oifs for my client on the network connected by eth0. Everything seems to be in order. The route cache is good (correct me if I'm wrong). I also have "1" in ALL of the following files:
/proc/sys/net/ipv4/conf/all/mc_forwarding
/proc/sys/net/ipv4/conf/eth0/mc_forwarding
/proc/sys/net/ipv4/conf/eth2/mc_forwarding
/proc/sys/net/ipv4/ip_forward
But, in spite of all that, it just won't forward the packets. Is there anything else missing?
Who?
Here we go...
As in all other Linux multicast routing threads I've seen anywhere, the matter dies without any resolution.
Who would be the best person to ask about this on the Linux kernel networking stack crew?
How to make multicast forwarding work
We have been trying to set up IPv6 multicast routing using xorp and vlc. I googled this website to find solution but found problem. Later we figured out the solution. Hopefully, our solution will work for you. Simply make sure your mc_forwarding flag is set to 1.
echo 1 > /proc/sys/net/ipv6/conf/all/mc_forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/mc_forwarding
Re: How to make multicast forwarding work
stevec -
What kernel are you running? Do you have usagi loaded? The only place that i can find /proc/sys/net/ipv6/conf/all/mc_forwarding is in usagi. Is there some other way to get this functionality?
Thanks!
I don't think you can set
I don't think you can set this through /proc/sys/net/ipv4/conf/mc_forwarding, in kernel code its file attribute: 0444, it is read only even you are root.
XORP, VLC for IPv6 Multicasting
We have xorp and vlc running on the source and the destination. Our Linux kernel is 2.6.15. There is only one router in between the source node and destination node. We did set up mc_forwarding to 1. But somehow traffic does not flow past the router that is running xorp daemon. Any help would be appreciated.
Regards
Ashutosh Dutta
Hello there, I don't know
Hello there,
I don't know about 3 or 4, but here's some anyway.
1. I think you're at the wrong layer here. Multicasting operates primarily at layer3. If you are using something other than UDP (TCP multicast doesn't make much sense) the concept of a port# might not even fit. An example of this is the OSPF HLO packet.
2. Once the socket closes, the groups should disappear. The kernel should also send out an igmp packet indicating that your host is leaving the group, and it should drop off the multicast routing caches of any mrouters on your network.
Probably you have to use smcr
Probably you have to use smcroute (an "modern" analogon to mrouted). The kernel performs routing. You must "say" to kernel, __how__ it will do it for you. This prog (smcroute) runs as daemon, intercepts all IGMP messages and writes an internal kernel vif-table.
Well...
As mentioned in previous replies on this thread, smcroute has been tried already. It also adds multicast routes to the cache, exactly the same as mrouted does, but the packets just won't forward.
I find it a little odd that you call smcroute a "modern" analog to mrouted. That would be like saying that manually entering your routes using the "route" command is a modern analog to ospf.
smcroute is the static tool. mrouted is dynamic.
Well
As mentioned in previous replies on this thread, smcroute has been tried already. It also adds multicast routes to the cache, exactly the same as mrouted does, but the packets just won't forward.
I find it a little odd that you call smcroute a "modern" analog to mrouted. That would be like saying that manually entering your routes using the "route" command is a modern analog to ospf.
smcroute is the static tool. mrouted is dynamic.
Is there a system file in proc/net where...????
Is there a system file where I can check the number of multicast packets sent over the network????
Yes, check out this..
To obtain statistics for mcast traffic check these files:
[root@host]# cat /proc/net/ip_mr_cache
Group Origin Iif Pkts Bytes Wrong Oifs
[root@host]# cat /proc/net/ip_mr_vif
Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote
I have no mcast configured here, but you can see BytesIn/Out and PacketsIn/Out per interface and packets/bytes per multicast group.
This fixed it for me
I had the exact same problem described above.
The multicast routes were set up correctly, but no packets were being forwarded.
However, there is an IP socket option called IP_MULTICAST_TTL, which by defalut is 1.
Setting it to 2 in the application using setsockopt fixed the problem for me.
I also heard that you can manipulate the ttl in the IP packet header using iptables,
if you don't have acces to the source code of the client.
multicast forwarding is not ok
I am also trying to do multicast forwarding in linux kernel (RHEL 5.0). with two ethernet interfaces. I have tried both options of mrouted and smcroute.
With mrouted, it is forwarding to the other interfaces, when we issue a -join command in the msend program, but the last node which is connected to the linux box which runs a mreceive program will not getting any multicast packets.
smcroute, it is the same case as mrouted.
However if I bridge the interface with brctl then everything works, even the VLC player I could able to stream and receive across 3 lans. But I dont know whether this is the right way to do it or not?