12 Dec
2012
12 Dec
'12
3:50 p.m.
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.
13 Dec
13 Dec
11:28 a.m.
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(a)fib.upc.edu>
To: udpcast(a)udpcast.linux.lu, Daniel Sanchez
Dorado <dani(a)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(a)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
14 Dec
14 Dec
12:09 p.m.
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(a)fib.upc.edu>
To: udpcast(a)udpcast.linux.lu, Daniel Sanchez
Dorado <dani(a)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(a)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
11:19 p.m.
On 14 Dec 2012 at 13:09, Daniel Sanchez Dorado wrote:
Date sent: Fri, 14 Dec 2012 13:09:42 +0100
From: Daniel Sanchez Dorado <dani(a)fib.upc.edu>
Copies to: udpcast(a)udpcast.linux.lu
Subject: Re: [Udpcast] IGMP missing
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!
This IGMP Membership looks interesting, but was wondering what
switches or do all switches support it? Did look for code example
to implement it, but did see full examples yet. I've got old 3com
switches in my classroom, and they have to have the Storm
setting turned off or they shutdown a udpcast session.
El 13/12/2012 12:28, Michael D. Setzer II escribió:
+----------------------------------------------------------+
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 13447067.706097 | EINSTEIN 9339400.249852
ROSETTA 5573843.390189 | ABC 15589623.987253
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(a)fib.upc.edu>
To: udpcast(a)udpcast.linux.lu, Daniel Sanchez
Dorado <dani(a)fib.upc.edu>
Subject: [Udpcast] IGMP missing
_______________________________________________
Udpcast mailing list
Udpcast(a)udpcast.linux.lu
https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast 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(a)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
20 Dec
20 Dec
4:31 p.m.
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!!
3478
days inactive
3486
days old
4 comments
2 participants
participants (2)
-
Daniel Sanchez Dorado -
Michael D. Setzer II