LinuxカーネルがマルチキャストUDPパケットを通過しない
最近、私は新しいUbuntu Server 10.04をセットアップしましたが、マルチキャストグループに参加した後でも、UDPサーバーがインターフェイスに送信されたマルチキャストデータを見ることができなくなりました。他の2台のUbuntu 8.04.4 LTSマシンでもまったく同じ設定を使用しており、同じマルチキャストグループに参加した後にデータを受信しても問題はありません。
イーサネットカードはBroadcom netXtreme II BCM5709であり、使用されるドライバーは次のとおりです。
b $ ethtool -i eth1
driver: bnx2
version: 2.0.2
firmware-version: 5.0.11 NCSI 2.0.5
bus-info: 0000:01:00.1
マルチキャスト登録を管理するためにsmcrouteを使用しています。
b$ smcroute -d
b$ smcroute -j eth1 233.37.54.71
グループに参加した後、ip maddrは新しく追加された登録を表示します。
b$ ip maddr
1: lo
inet 224.0.0.1
inet6 ff02::1
2: eth0
link 33:33:ff:40:c6:ad
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 224.0.0.1
inet6 ff02::1:ff40:c6ad
inet6 ff02::1
3: eth1
link 01:00:5e:25:36:47
link 01:00:5e:25:36:3e
link 01:00:5e:25:36:3d
link 33:33:ff:40:c6:af
link 01:00:5e:00:00:01
link 33:33:00:00:00:01
inet 233.37.54.71 <------- McastGroup.
inet 224.0.0.1
inet6 ff02::1:ff40:c6af
inet6 ff02::1
これまでのところ、このマルチキャストグループのデータを受信していることがわかります。
b$ Sudo tcpdump -i eth1 -s 65534 Host 233.37.54.71
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65534 bytes
09:30:09.924337 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:09.947547 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
09:30:10.108378 IP 192.164.1.120.58866 > 233.37.54.71.15574: UDP, length 268
09:30:10.196841 IP 192.164.1.120.58848 > 233.37.54.71.15572: UDP, length 212
...
インターフェイスがmcastパケットを受信していることも確認できます。
b $ ethtool -S eth1 | grep mcast_pack
rx_mcast_packets: 103998
tx_mcast_packets: 33
今ここに問題があります。単純なRuby UDPサーバーを使用してトラフィックをキャプチャしようとすると、ゼロのデータを受信します！これは、ポート15572で送信されたデータを読み取り、最初の2文字を出力する単純なサーバーです。これは2つで機能します8.04.4 Ubuntuサーバー（10.04サーバーは除く）。
require 'socket'
s = UDPSocket.new
s.bind("", 15572)
5.times do
text, sender = s.recvfrom(2)
puts text
end
Ruby=で作成されたUDPパケットをlocalhostに送信すると、サーバーはそれを受信して最初の2文字を出力します。そのため、上記のサーバーは正常に動作しています。
irb(main):001:0> require 'socket'
=> true
irb(main):002:0> s = UDPSocket.new
=> #<UDPSocket:0x7f3ccd6615f0>
irb(main):003:0> s.send("I2 XXX", 0, 'localhost', 15572)
プロトコル統計を確認すると、InMcastPktsが増加していないことがわかります。他の8.04サーバー上では、同じネットワーク上で、10秒間に数千のパケットを受信しました。
b $ netstat -sgu ; sleep 10 ; netstat -sgu
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4654 <--------- Same as below
OutMcastPkts: 3426
InBcastPkts: 9854
InOctets: -1691733021
OutOctets: 51187936
InMcastOctets: 145207
OutMcastOctets: 109680
InBcastOctets: 1246341
IcmpMsg:
InType3: 11
OutType3: 11
Udp:
446 packets received
4 packets to unknown port received.
0 packet receive errors
461 packets sent
UdpLite:
IpExt:
InMcastPkts: 4656 <-------------- Same as above
OutMcastPkts: 3427
InBcastPkts: 9854
InOctets: -1690886265
OutOctets: 51188788
InMcastOctets: 145267
OutMcastOctets: 109712
InBcastOctets: 1246341
インターフェイスを無差別モードに強制しようとしても、何も変わりません。
この時点で行き詰まっています。カーネル構成でマルチキャストが有効になっていることを確認しました。おそらく私がチェックすべき他の設定オプションがありますか？
b $ grep CONFIG_IP_MULTICAST /boot/config-2.6.32-23-server
CONFIG_IP_MULTICAST=y
ここからどこへ行くかについての考えはありますか？
私たちの例では、問題はMaciejとは異なるsysctlパラメータによって解決されました。
OP（buecking）については話さないことに注意してください。基本的な詳細（ユーザーランドにマルチキャストトラフィックがない）に関連する問題のため、この投稿にアクセスしました。
（通常）受信サーバーのインターフェースに直接接続されているアプライアンスから、4つのマルチキャストアドレスに送信されたデータと、マルチキャストアドレスごとに一意のポートを読み取るアプリケーションがあります。
既知の理由もなく不思議なことに失敗したときに、お客様のサイトにこのソフトウェアを導入しようとしました。このソフトウェアをデバッグしようとすると、すべてのシステムコールが検査され、最終的にはすべて同じことがわかりました。
私たちのソフトウェアはデータを要求し、OSは何も提供しません。
マルチキャストパケットカウンターが増加し、tcpdumpはボックス/特定のインターフェイスに到達するトラフィックを示しましたが、それを使用して何もできませんでした。 SELinuxは無効化され、iptablesは実行されていましたが、どのテーブルにもルールがありませんでした。
困惑しました。
ランダムに突っ込んで、sysctlが処理するカーネルパラメーターについて考え始めましたが、文書化された機能のいずれも特に関連性がなかったか、マルチキャストトラフィックと関係がある場合は有効になりました。ああ、そしてifconfigは、機能ライン（アップ、ブロードキャスト、実行中、マルチキャスト）に「マルチキャスト」をリストしました。好奇心から、私たちは/etc/sysctl.conf。なんと、この顧客のベースイメージの下部に2、3行追加されました。
私たちの場合、顧客はnet.ipv4.all.rp_filter = 1。 rp_filterはルートパスフィルターで、（私が理解しているように）このボックスに到達できなかった可能性のあるすべてのトラフィックを拒否します。ネットワークサブネットホッピング。ソースIPが偽装されていると考えられている。
さて、このサーバーは192.168.1/24サブネット上にあり、マルチキャストトラフィックのアプライアンスのソースIPアドレスは10. *ネットワークのどこかにありました。したがって、フィルタにより、サーバーはトラフィックに対して意味のある処理を行うことができませんでした。
お客様によって承認されたいくつかの微調整。 net.ipv4.eth0.rp_filter = 1およびnet.ipv4.eth1.rp_filter = 0そして私たちは幸せに走っていました。
TL/DRまた、マルチキャストがVLANからのものでないことを確認してください。 tcpdump -eは、そうであるかどうかを判断するのに役立ちます。
公平に言えば、誰かがマルチキャストがユーザーランドに到達するのを妨げる可能性のある事柄のチェックリストを含むページを作成すべきです。私はこれに数日間苦労してきましたが、当然のことながらWebで見つけられなかったものは何も助けになりませんでした。
tcpdumpでパケットを確認できるだけでなく、実際には、別のインターフェイスで、他のプロデューサー向けの他のマルチキャストパケットを受信することもできました。マルチキャストを受信できるかどうかのテストに使用したコマンドは次のとおりです。
$ GRP=224.x.x.x # set me to the group
$ PORT=yyyy # set me to the receiving port
$ IFACE=mmmm # set me to the name or IP address of the interface
$ strace -f socat - UDP4-DATAGRAM:$GRP:$PORT,ip-add-membership=$GRP:$IFACE,bind=0.0.0.0:$PORT,multicast-loop=0
ここでstraceを使用する理由は、実際にsocatでパケットをstdoutに出力できなかったためです。ただし、strace出力では、socatはバインドされたソケットから実際のデータを受信しています（それ以外の場合は、最初のselect呼び出しの後にミュートされます）
rp_filtersysctl-適用されません、システムは同じIPネットワーク上にあります（私はそれらを0にすべて同じに設定しましたが、1は現在少なくともデフォルトの設定になっているようですUbuntu）。- firewalls/etc-受信側システムはファイアウォールなしです（ファイアウォールが設定されている場合、パケットはtcpdumpに表示されないと思いますが、ファイアウォールがおかしい場合は可能だと思います）
- IP /マルチキャストルーティングと複数のインターフェース-正しいインターフェースでグループに明示的に参加しました
- 奇抜なネットワークハードウェア-これが私の最後の手段でしたが、一部のラップトップをIntelに変更しましたNUC=助けにはなりませんでした。これは、私が肘を噛み始め、これをSEに投稿し続けたところです。
- 私の場合の問題は、これらのマルチキャストパケットを生成していた専用ハードウェアによるVLANの使用でした。これが問題であるかどうかを確認するには、
tcpdumpに-eフラグを含めて、vlanタグを確認してください。ユーザーランドがこれらのパケットを取得できるようにするには、正しいVLANへのインターフェイスを構成する必要があります。実際のところ、私にとっては、マルチキャストプロデューサーはpingを実行しませんが、ARPキャッシュにはアクセスしませんが、ARP応答ははっきりと確認できました。
VLAN this link で実行するには、マルチキャストルーティングを構成するのに役立ちます。残念ながら、これは初めてなので、レピュテーションで回答を追加できません。 。したがって、この編集。）
これが私がしたことです（必要に応じてSudoを使用してください）：
ip link add link eth0 name eth0_100 type vlan id 100
ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth0_100
ip link set dev eth0_100 up
ip maddr add 01:00:5e:01:01:01 dev eth0_100
route -n add -net 224.0.0.0 netmask 240.0.0.0 dev eth0_100
このように、vlan id 100のvlanトラフィック用に作成された追加のインターフェース。vlanipは不要な場合があります。次に、マルチキャストアドレスが新しいインターフェイスに構成され（01：00：5e：01：01：01は239.1.1.1のリンク層アドレスです）、すべての着信マルチキャストトラフィックはeth0_100にバインドされます。また、上記の回答で可能なすべての手順を実行しました（iptables、rp_filterなどを確認してください）。
次の設定を試してみてください。
proc
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
sysctl.conf
sed -i -e 's|^net.ipv4.icmp_echo_ignore_broadcasts =.*|net.ipv4.icmp_echo_ignore_broadcasts = 0|g' /etc/sysctl.conf
これらは、RHELでマルチキャストを有効にするために使用されています。
ファイアウォールがマルチキャストトラフィックを許可していることを確認してください。再びRHELを使用して、以下を有効にしました。
# allow anything in on multicast addresses
-A INPUT -s 224.0.0.0/4 -j ACCEPT
-A INPUT -p igmp -d 224.0.0.0/4 -j ACCEPT
# needed for multicast ping responses
-A INPUT -p icmp --icmp-type 0 -j ACCEPT
s.bind("", 15572)
について）わかっている ""？マルチキャストIPアドレスを使用してバインドしないのはなぜですか？
マネージドスイッチを使用していますか？一部には、「ブロードキャストストーム」やその他のマルチキャストの問題を防止するオプションがあり、特定のタイプのパケットを防止します。スイッチのドキュメントをご覧になることをお勧めします。