[mpenning@Finger ~]$ sudo tshark -n -V -i eth0 igmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
Frame 1 (54 bytes on wire, 54 bytes captured)
    Arrival Time: Dec  6, 2011 09:08:45.156782000
    ... >snip< ...
Internet Protocol, Src: 192.168.12.238 (192.168.12.238), Dst: 224.0.0.22 (224.0.0.22)
    Version: 4
    Header length: 24 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 1
    Protocol: IGMP (0x02)
    Header checksum: 0x3663 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.12.238 (192.168.12.238)
    Destination: 224.0.0.22 (224.0.0.22)
    Options: (4 bytes)
        Router Alert: Every router examines packet
Internet Group Management Protocol
    [IGMP Version: 3]
    Type: Membership Report (0x22)
    Header checksum: 0xe9fd [correct]
    Num Group Records: 1
    Group Record : 239.255.0.1  Change To Exclude Mode
        Record Type: Change To Exclude Mode (4)
        Aux Data Len: 0
        Num Src: 0
        Multicast Address: 239.255.0.1 (239.255.0.1)

^C1 packet captured

现在检查多播源的流量是否到达此接口（我假设它是 eth0，如下）：

sudo tshark -n -i eth0 ip and host 239.255.0.1

如果您看到流量发送到正确的多播组，则直接继续步骤 3；否则请转至步骤 2。

步骤 2

接下来确保您的多播服务器将流量发送到正确的组。在下面的示例中，我运行命令来嗅探 eth0 发送到 239.255.0.1 的流量。

[mpenning@hotcoffee Models]$ sudo tshark -n -i eth0 ip and host 239.255.0.1

1.466991 192.168.12.236 -> 239.255.0.1  UDP Source port: 11111  Destination port: 11111

如果多播源在步骤 2 中将流量发送到正确的组，您在步骤 1 中看到 IGMP 组加入，而步骤 1 在多播接收者的接口上没有看到流量，那么请联系您的网络管理员了解此问题。

步骤 3

假设所有这些都有效，并且您仍然需要进行严格测试，以防您的多播接收器软件以某种方式丢弃从 IP 堆栈接收到的多播...确保您的计算机上安装了 socat 并且执行以下操作...

在组播发送方（服务器）上，使用此命令将测试组播数据包发送到 239.255.0.1：

perl -e '$ii=0; while (1) { print "hi number $ii\n"; $ii++; }' | socat - UDP-SENDTO:239.255.0.1:11111,sp=11111

在组播接收方（客户端）上，使用此命令侦听测试组播数据包发送到eth0 上的 239.255.0.1：

socat - UDP-DATAGRAM:239.255.0.1:11111,bind=:11111,ip-add-membership=239.255.0.1:eth0

假设您的网络管理员允许在 239.255.0.1 上进行多播，您将在多播接收者的终端窗口：

hi number 212289
hi number 212290
hi number 212291
hi number 212292
hi number 212293
hi number 212294
hi number 212295
hi number 212296
hi number 212297
hi number 212298

注意：不要使用网络上已在生产使用的多播组地址尝试此操作。

步骤 4

如果步骤 1、2 和 3 显示正在通过您的网络发送和接收多播流量，请致电软件开发人员并告诉他们您认为应用程序存在问题，并解释您迄今为止所采取的步骤。

如果步骤 1、2 或 3 不起作用，请重新配置您的软件/主机/网络，直到它们起作用为止。警告，在 IP 网络中正确实施多播的难度是 IP 单播的 3 倍。

祝你好运...

When troubleshooting IP multicast, there are some big-picture things you can do to isolate whether this is a host issue, software issue, or network issue:

Step 1: Ensure the receiver is sending IGMP group joins on the correct interface. Look for the multicast source's traffic on the receiver's interface.
Step 2: Ensure the server is sending traffic on the proper multicast group out the correct interface
Step 3: Perform something like a ping test for IP multicast (using linux's socat tool)

The details for each step are outlined below...

Step 1

First, ensure that the linux multicast receivers are correctly advertising their group membership reports; keep in mind that a lot of things in multicast work backwards from unicast. For instance, multicasting requires that you send an IGMP join packet that contains the multicast group you want to receive.

Use tcpdump or tshark to examine the interface in question... In the example below, I have a machine on 192.168.12.238 that is announcing (via igmp) that it wants to receive multicast traffic from 239.255.0.1

[mpenning@Finger ~]$ sudo tshark -n -V -i eth0 igmp
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
Frame 1 (54 bytes on wire, 54 bytes captured)
    Arrival Time: Dec  6, 2011 09:08:45.156782000
    ... >snip< ...
Internet Protocol, Src: 192.168.12.238 (192.168.12.238), Dst: 224.0.0.22 (224.0.0.22)
    Version: 4
    Header length: 24 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0.. = Reserved bit: Not Set
        .1. = Don't fragment: Set
        ..0 = More fragments: Not Set
    Fragment offset: 0
    Time to live: 1
    Protocol: IGMP (0x02)
    Header checksum: 0x3663 [correct]
        [Good: True]
        [Bad : False]
    Source: 192.168.12.238 (192.168.12.238)
    Destination: 224.0.0.22 (224.0.0.22)
    Options: (4 bytes)
        Router Alert: Every router examines packet
Internet Group Management Protocol
    [IGMP Version: 3]
    Type: Membership Report (0x22)
    Header checksum: 0xe9fd [correct]
    Num Group Records: 1
    Group Record : 239.255.0.1  Change To Exclude Mode
        Record Type: Change To Exclude Mode (4)
        Aux Data Len: 0
        Num Src: 0
        Multicast Address: 239.255.0.1 (239.255.0.1)

^C1 packet captured

Now check and see whether the multicast source's traffic is getting to this interface (I'm assuming it was eth0, below):

sudo tshark -n -i eth0 ip and host 239.255.0.1

If you see traffic sent to the proper multicast group, then proceed directly to Step 3; otherwise go to Step 2.

Step 2

Next ensure that your multicast server is sending the traffic to the correct group. In the example below, I run a command to sniff eth0 for traffic sent to 239.255.0.1.

[mpenning@hotcoffee Models]$ sudo tshark -n -i eth0 ip and host 239.255.0.1

1.466991 192.168.12.236 -> 239.255.0.1  UDP Source port: 11111  Destination port: 11111

If the multicast source is sending traffic to the right group here in Step 2, you saw IGMP group joins in Step 1, and Step 1 did not see traffic at the multicast receiver's interface, then contact your network administrators about this problem.

Step 3

Assuming all that works, and you still want an acid test in case your multicast receiver software is somehow discarding multicast it receives from the IP stack... make sure you have socat installed on your machine and do the following...

On the multicast sender (server), use this command to send test multicast packets to 239.255.0.1:

perl -e '$ii=0; while (1) { print "hi number $ii\n"; $ii++; }' | socat - UDP-SENDTO:239.255.0.1:11111,sp=11111

On the multicast receiver (client), use this command to listen to test multicast packets sent to 239.255.0.1 on eth0:

socat - UDP-DATAGRAM:239.255.0.1:11111,bind=:11111,ip-add-membership=239.255.0.1:eth0

Assuming your network administrators are allowing multicast on 239.255.0.1, you will see a lot of traffic like this in the multicast receiver's terminal window:

hi number 212289
hi number 212290
hi number 212291
hi number 212292
hi number 212293
hi number 212294
hi number 212295
hi number 212296
hi number 212297
hi number 212298

NOTE: do not try this with a multicast group address that is already in production use on your network.

Step 4

If steps 1, 2, and 3 reveal that multicast traffic is being sent and received through your network, then call up the software developer and tell them you think there is a problem with the application and explain the steps you have taken so far.

If steps 1, 2, or 3 do not work, reconfigure your software / hosts / network until they do. Warning, multicast in IP networks is 3x harder to implement correctly than IP unicast.

Best of luck to you...

回复收藏 0 原文

ぇ气 2024-12-26 11:26:36

如何检查多播？

当集群中断时，可能是由于多种原因造成的。其中之一是多播（应用程序订阅某个 IP 地址并侦听消息）。如果用户发现自己间歇性地注销，则可能表明存在此类问题。

多播 IP 地址的范围为 224.0.0.0 到 239.255.255.255。
这篇文章只是提醒我在 Linux 级别要做什么检查：

运行 netstat -g 来获取该主机订阅的多播地址。

[root@bruatwls001 ~]$ netstat -g IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 all-systems.mcast.net eth0 2 239.128.4.0 eth0 1 all-systems.mcast.net

注意，RefCnt 列中显示有 2 个成员属于组 239.128.4.0

Ping 该多播地址可显示哪些成员订阅了该组（或集群）：

< /i>

[root@bruatwls001 ~]$ ping 239.128.4.0 PING 239.128.4.0 (239.128.4.0) 56(84) bytes of data. 64 bytes from 10.35.8.12: icmp_seq=0 ttl=64 time=0.032 ms 64 bytes from 10.35.8.13: icmp_seq=0 ttl=64 time=0.207 ms (DUP!) 64 bytes from 10.35.8.12: icmp_seq=1 ttl=64 time=0.029 ms 64 bytes from 10.35.8.13: icmp_seq=1 ttl=64 time=0.193 ms (DUP!) 64 bytes from 10.35.8.12: icmp_seq=2 ttl=64 time=0.028 ms 64 bytes from 10.35.8.13: icmp_seq=2 ttl=64 time=0.241 ms (DUP!)

jgroups

测试多播的一个好方法是使用 jgroups。请参阅http://www.jgroups.org/manual/html/ch02.html#它不起作用
下载 jgroups-3.3.3.Final.jar

启动接收器：

[quick@laptop]$ java -cp jgroups-3.3.3.Final.jar org.jgroups.tests.McastReceiverTest -mcast_addr 231.12.21.132 -port 45566 Socket=0.0.0.0/0.0.0.0:45566, bind interface=/fe80:0:0:0:201:4aff:fe5e:5331%2 Socket=0.0.0.0/0.0.0.0:45566, bind interface=/192.168.1.5 Socket=0.0.0.0/0.0.0.0:45566, bind interface=/0:0:0:0:0:0:0:1%1 Socket=0.0.0.0/0.0.0.0:45566, bind interface=/127.0.0.1

启动发送器并输入内容：

[quick@centos ~]$ java -cp jgroups-3.3.3.Final.jar org.jgroups.tests.McastSenderTest -mcast_addr 231.12.21.132 -port 45566 Socket #1=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/fe80:0:0:0:fc54:ff:fedc:d6da%7 Socket #2=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/fe80:0:0:0:21d:7dff:fe03:4cf5%2 Socket #7=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/192.168.122.1 Socket #8=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/fe80:0:0:0:21d:7dff:fe03:4cf5%2 Socket #9=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/fe80:0:0:0:21d:7dff:fe03:4cf5%3 Socket #10=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/0:0:0:0:0:0:0:1%1 Socket #11=0.0.0.0/0.0.0.0:45566, ttl=32, bind interface=/127.0.0.1 > helloworld > quit

消息出现在接收者窗口中并显示发送者：

helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566]

How to check Multicasting ?

When clustering breaks, it could be due to a number of reasons. One of them is multicasting (where applications subscribe to a certain IP address and listen for messages). If users find themselves intermittently logged out, this might indicate such a problem.

A multicast IP address will be in the range 224.0.0.0 to 239.255.255.255.
This post is just a reminder to me what checks to do at the linux level:

Run netstat -g to get the multicast addresses this host subscribes to.

Note in the RefCnt column it shows 2 members belong to the group 239.128.4.0

Pinging this multicast address reveals which members subscribe to the group (or cluster):

jgroups

A good way to test multicasting is using jgroups. See http://www.jgroups.org/manual/html/ch02.html#ItDoesntWork
Download jgroups-3.3.3.Final.jar

Start the receiver:

Start the sender and type something:

The message appears in the receiver window and displays the sender:

helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566] helloworld [sender=192.168.1.20:45566]

回复收藏 0 原文