Yes, IGMP Snooping is enabled, but IGMP Snooping only works if the sender sends a IGMP Membership to the multicast group. A switch is not able to detect multicast traffic directly, because it's a layer 2 device. IGMP Snooping feauture allows a switch, (layer 2) detect a IGMP (layer 3) packet, but not the multicast traffic directly.

I have checked-out the tunning list. His hints are fantastic to constraint the flow, but i am trying to avoid it.

Thank you very much!

El 13/12/2012 12:28, Michael D. Setzer II escribió:

Did you check out the Tuning hints on this page.

http://www.udpcast.linux.lu/hints.html

IGMP snooping is suppose to be enable.

On 12 Dec 2012 at 16:50, Daniel Sanchez Dorado wrote:

Date sent: Wed, 12 Dec 2012 16:50:26 +0100 From: Daniel Sanchez Dorado dani@fib.upc.edu To: udpcast@udpcast.linux.lu, Daniel Sanchez Dorado dani@fib.upc.edu Subject: [Udpcast] IGMP missing

...

Hello, I'm the network administrator at the Barcelona School of Informatics, in Barcelona, Spain. We are testing a spanish deployment tool, Opengnsys, that uses udpcast for massive file distribution, via multicast. In our tests, we have found that udpcast floods our network with multicast traffic, and this is a big problem for us. We have other multicast products for many years, like Rembo, and there is no problem about flooding.

We have been sniffing and analyzing udpcast protocols, and we think that the problem is in the IGMP signaling. We haven't capture any IGMP packet. We have analyzed the source code, and we haven't been able to locate any reference to IGMP. Usually, the standard solution is generating an IGMP-Group Specific query, to subscribe the receiver to the group. With this step, you join a multicast group. Then, when the sender broadcast the multicast traffic, the network is capable to switch the packets only to the subscribed ports.

We have found, that our switches, are not capable of locate multicast receivers PCs, because they don't see the IGMP packet. IGMP snooping is enabled, and it allows the switches identify multicast, but, it doesn't work.

These are our testing scripts:

RECEIVER: ./udp-receiver --file /tmp/dst.iso --interface eth0 --nokbd

SENDER: ./udp-sender --file /tmp/wi7_pr64_000.iso --full-duplex --interface eth0 --autostart 30 --nokbd

Sender and receiver are Linux machines, in the same subnet, without any kind of firewalls. The file arrives fine, but, the multicast traffic floods other ports. The switch involved is a cisco C3560G-48PS, with igmp snooping enabled, and there is multicast enabled router (Cisco 3750G-48TS) for querier in this VLAN. Our switches don't make any IGMP-snoop link.

Any idea?

Thanks in advance.

---

Udpcast mailing list Udpcast@udpcast.linux.lu https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast

+----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@kuentos.guam.net mailto:msetzerii@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+

http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)

BOINC@HOME CREDITS SETI 13433430.620274 | EINSTEIN 9327387.979852 ROSETTA 5557723.215864 | ABC 15587656.017131

Hello!!! I have been testing the igmp system in udp-cast. I have discovered that is not necessary to manual send any IGMP packet. This entire job is done by the linux kernel. It’s very important define the socket as a multicast socket. This is done setting IP_ADD_MEMBERSHIP option. This is done in this line:

(source code, file socklib.c, line 418)

static int mcastListen(int sock, net_if_t *net_if, struct sockaddr_in *addr) { return mcastOp(sock, net_if, getSinAddr(addr), IP_ADD_MEMBERSHIP, "Subscribe to multicast group"); }

With this definition, the system controls the IGMP session. When you open the socket, the linux kernel sends the IGMP Membership to join this group. And, when you close the socket, the linux kernel sends the IGMP Leave. During the session, the kernel sends the notifications to maintain the group.

It's very important ensure the igmp support in the kernel. To avoid compatibility problems, it's also important to verify the IGMP version in router and clients.

To see the IGMP table, you can:

cat /proc/net/igmp

dx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V3 010000E0 1 0:00000000 0 2 eth0 : 2 V2 250000E1 1 0:00000000 1 010000E0 1 0:00000000 0

IGMP group table:

netstat -gn

IPv6/IPv4 Group Memberships Interface RefCnt Group --------------- ------ --------------------- lo 1 224.0.0.1 eth0 1 225.0.0.37 eth0 1 224.0.0.1 lo 1 ff02::1 eth0 1 ff02::1:ff04:c68b eth0 1 ff02::1

IGMP groups registered:

ip maddr

1: lo inet 224.0.0.1 inet6 ff02::1 2: eth0 link 01:00:5e:00:00:01 link 33:33:00:00:00:01 link 33:33:ff:04:c6:8b link 01:00:5e:00:00:25 inet 225.0.0.37 inet 224.0.0.1 inet6 ff02::1:ff04:c68b inet6 ff02::1

Force IGMP version echo "2" > /proc/sys/net/ipv4/conf/eth<X>/force_igmp_version (to force v2)

My problem was that udp-cast uses a broadcast to locate clients and servers, and then, there is no multicast traffic sent. If you specify a ttl>1, then, all the igmp process is initiated normally.

There was another problem: the igmp packet is only sent when the client when you open the socket, not immediately. The udp-receiver waits for udp-sender signal to register the multicast generated group.

Finally, I have to say that all works perfect, it was bad testing options! Congratulations for your software!!