linux udp组播接收问题及原理分析

转自 http://blog.csdn.net/rcfalcon/article/details/35221759

现象：

在某个网络环境下，同一个udp组播源（igmpv2），同样的收流代码，在windows上能收到，linux上收不到。排除网络拓扑结构、编程语言、硬件驱动等问题，我们就此问题来分析原理及解决方案。

环境：

交换机出，组播地址224.X.X.X，机器多网卡，eth0收流

配置静态IP地址，已关闭NetworkManager服务，iptables规则配置没有问题

实验：

1、在不同的LINUX发行版（opensuse、centos、ubuntu）上进行测试：均收不到。

2、直接tcpdump：收不到

3、配置一条路由 route add -net 224.0.0.1 netmask 255.0.0.0 dev eth0，重启网卡：能收到流，约1分钟以后断掉，重启收流程序没有反应

4、重复3测试，发现规律：每次重启网卡后，配置路由，大概能收流1分钟，就再也收不到流了

5、将路由配置成 route add -net 0.0.0.0 netmask 0.0.0.0 dev eth0，重启网卡：能稳定收流了

分析：

1、与LINUX发行版无关，而是LINUX内核统一的问题。

2、IGMP V2客户端不请求的时候，交换机不会将组播分配到网卡。

3、4、5： 这里需要结合一下IGMP V2协议的原理：

①交换机将询问所有的网内机器，谁需要加入组播组

②若一台主机需要加入组播组，需要发送入组报文

③交换机收到入组报文，给主机分发IP数据报文

④退组机制有两种：1、主机主动退出（发出退出报文） 2、交换机轮询存活主机没有响应（超时）

可以看到，问题大概就出在这里。

具体的我查阅了IGMP原理手册，IGMP各种信令报文走的无外乎224.0.0.1 或224.1.1.1（不知是否可配），怀疑255.0.0.0将主机对于IGMPV2的存活查询反馈报文给过滤了，而这种反馈报文每次未必走的一样的地址，包括入组报文，后续也发不出去了。

解决方法：

1、暴力流：直接将路由的全局出口均走收流网卡（ route add -net 0.0.0.0 netmask 0.0.0.0 dev eth0），其他网卡若需要通信，单独配路由。

2、待研究：需要仔细研究IGMPV2的信令发送（不知是否和交换机配置相关），来配置合适的路由规则。

这里要说一下windows为什么不用关心这些，我理解windows自身有一个编写的比较好的NetworkManager服务，能够根据应用程序的请求灵活配置路由规则，这里不详细研究了。总之，若同样的网络环境，LINUX收组播流有各种奇葩问题，基本都是路由配置的问题。