[Udpcast] Info on UDPcast IGMP packets
Manon.Lessard at sit.ulaval.ca
Fri Feb 10 15:25:46 CET 2006
De : Alain Knaff [mailto:alain at knaff.lu]
Envoyé : February 10, 2006 4:48 AM
À : Manon Lessard
Cc : udpcast at udpcast.linux.lu
Objet : Re: [Udpcast] Info on UDPcast IGMP packets
Manon Lessard wrote:
> I work for the telecom dept of a large university and we are currently
> working with some UDPcast users on a very strange problem.
> It appears they are unable to start a cast on a given group of machines.
Where exactly does it fail? Can receivers still correctly register with
the sender (Sender displays New connection from 192.168.1.10 (#0)
00000009). Are no multicast packets received at all on receiver, or is
there only a very high loss rate?
Knowing on exactly when udpcast starts failing may help point to a
source of the problem.
The stations register with the server. However the cast never starts...or almost never...and if it does...well it will eventually freeze...
I doubt the MTU has anything to do with it...
> These clients are using a version of UDPcast dating from dec. 04.
> Are you aware of anything in UDPcast or any incompatibilities with some
> Cisco IOS versions that could cause this problem?
I checked with a colleague, and he told me that the Cisco equipment
needs to be specifically configured for correctly understanding IGMP
(because usually they use a proprietary protocol, CGMP). The equipment
needs to be configured to understand IGMP v3 and PIM v2. Symptoms of
failure in this area is that receivers can actually register with the
server, but transfer will not start (or conversely, transfer will start,
but traffic will also be blasted out of those switch ports where no
participating receiver is connected. This latter failure mode, where
multicast is basically treated as broadcast is much more common that the
case that you are observing)
We currently support only IGMP v2. V3 is out of the question for the moment. Did Udpcast require v2 at some point because this thing has worked before and isn't working anymore...if they could fix it by reverting to an older version that would make everyone happy. Very happy.
I doubt it's the ttl and we do not use storm protection.
If nothing else helps, you can try to instruct udp-sender to use
broadcast, rather than multicast, by adding the --broadcast flag to its
command line (but in that case, traffic will spread over your whole
network, not just the machines that are actually participating)
I could tell them to do that... and have my L3 switch reach 100% cpu, thus implying that I'd voluntarily cause a network outage on a third of our network. You should mention something about that (ie can make the cpu of the router reach 100%) in your documentation (you might already mention it, I have to say I haven't read it...). The thing is that in campus environments the techs and analysts out in the field are not necessarily well aware of the impact their work might have on the net infrastructure and other users...
When they did try the broadcast function they successfully caused an outage and we had to shut them down before they had the chance to cast their image...
In any case, thanks for your quick reply...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Udpcast