[Udpcast] Info on UDPcast IGMP packets

Manon Lessard Manon.Lessard at sit.ulaval.ca
Fri Feb 10 15:25:46 CET 2006


-----Message d'origine-----
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:

> Hi

> 

> 

> 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...

 

 

Regards,

 

 

 

M

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20060210/62e93a47/attachment.html>


More information about the Udpcast mailing list