linux udp組播接收問題及原理分析

現象：在某個網路環境下，同乙個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收組播流有各種奇葩問題，基本都是路由配置的問題。