Subject: Linux: mrouted now OK, group timeouts happening

From: Malcolm Beattie <[email-masked]>
Date: Tue, 23 Jul 1996 15:20:31 +0100 (BST)

I'm one of the people trying out mrouted with recent Linux kernels.
Linux 2.0.8 (I'm actually running 2.0.7 + the multicast patchkit
that went into 2.0.8) seems to cure all the problems I'd been having
with mrouted. I now have an mrouted tunnel between a Linux box and
a Sun. The problems we'd been having with the Sun (not running Linux)
was that as soon as the tunnel came up, it would log "socket queue
full" messages from the kernel and make the machine unusable until
mrouted was killed. It turned out that the machine wasn't powerful
enough: its administrator upgraded it and it now seems fine. There
are about 3000 routes in the mrouted tables now; I'll assume this is
normal unless someone tells me otherwise.

While running mbone applications (e.g. sdr and vic) under Linux,
I'm noticing a problem which I seem to recall happened under
Linux 1.2.13 as well. The symptom is that after about 5 minutes
of starting up the application and it working fine, the data stops
arriving. For example, using sdr to start up a vic session displays
pretty pictures nicely for 5 minutes, after which the picture
freezes and eventually is replaced by a "waiting for video" message.
Quitting vic and restarting it brings back the pictures immediately
(or at least, as fast as it can be re-displayed). I believe what is
happening is that the kernel is failing to send IGMP membership
reports as often as it should (at all?) or pehaps failing to respond
to requests about group membership.

Right after starting up vic to watch a session being multicast from
193.61.212.131 to group 224.2.23.228, mtrace shows:

[~]plutonium# mtrace 193.61.212.131 224.2.23.228
Mtrace from 193.61.212.131 to 163.1.32.155 via group 224.2.23.228
Querying full reverse path... 
  0  plutonium.oucs.ox.ac.uk (163.1.32.155)
 -1  plutonium.oucs.ox.ac.uk (163.1.32.155)  DVMRP  thresh^ 1  
 -2  orac.physics.ox.ac.uk (163.1.244.8)  DVMRP  thresh^ 24  
 -3  noc.rl.ja.net (193.63.104.100)  DVMRP  thresh^ 24  
 -4  noc.bath.ja.net (193.63.110.100)  DVMRP  thresh^ 24  
 -5  dir.aber.ac.uk (144.124.16.6)  DVMRP  thresh^ 24  
 -6  sprout.dcs.aber.ac.uk (193.61.212.130)  DVMRP  thresh^ 8  
 -7  parsnip.dcs.aber.ac.uk (193.61.212.131)
Round trip time 669 ms

Waiting to accumulate statistics... Results after 10 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
193.61.212.131  163.1.32.155     All Multicast Traffic     From 193.61.212.131
     v       __/  rtt  968 ms    Lost/Sent = Pct  Rate       To 224.2.23.228
193.61.212.130  sprout.dcs.aber.ac.uk 
     v     ^      ttl    8        5/104  =  5%  10 pps     5/34   = 15%   3 pps
144.124.16.6    dir.aber.ac.uk 
     v     ^      ttl   24        0/99   =  0%   9 pps     0/29   =  0%   2 pps
193.63.110.100  noc.bath.ja.net 
     v     ^      ttl   25        1/99   =  1%   9 pps     1/29   =  3%   2 pps
193.63.104.100  noc.rl.ja.net  
     v     ^      ttl   26       -3/209  =  0%  20 pps     0/28   =  0%   2 pps
163.1.244.8     orac.physics.ox.ac.uk 
     v     ^      ttl   27          202         20 pps       28           2 pps
163.1.32.155    plutonium.oucs.ox.ac.uk 
     v      \__   ttl   28          95           0 pps       0            0 pps
163.1.32.155    163.1.32.155
  Receiver      Query Source

Five minutes later after the picture freezes, mtrace shows

[~]plutonium# mtrace 193.61.212.131 224.2.23.228
Mtrace from 193.61.212.131 to 163.1.32.155 via group 224.2.23.228
Querying full reverse path... 
  0  plutonium.oucs.ox.ac.uk (163.1.32.155)
 -1  plutonium.oucs.ox.ac.uk (163.1.32.155)  DVMRP  thresh^ 1  Prune sent upstream
 -2  orac.physics.ox.ac.uk (163.1.244.8)  DVMRP  thresh^ 24  Prune sent upstream
 -3  noc.rl.ja.net (193.63.104.100)  DVMRP  thresh^ 24  Output pruned
 -4  noc.bath.ja.net (193.63.110.100)  DVMRP  thresh^ 24  
 -5  dir.aber.ac.uk (144.124.16.6)  DVMRP  thresh^ 24  
 -6  sprout.dcs.aber.ac.uk (193.61.212.130)  DVMRP  thresh^ 8  
 -7  parsnip.dcs.aber.ac.uk (193.61.212.131)
Round trip time 238 ms

Waiting to accumulate statistics... Results after 9 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
193.61.212.131  163.1.32.155     All Multicast Traffic     From 193.61.212.131
     v       __/  rtt  226 ms    Lost/Sent = Pct  Rate       To 224.2.23.228
193.61.212.130  sprout.dcs.aber.ac.uk 
     v     ^      ttl    8       15/310  =  5%  34 pps     0/31   =  0%   3 pps
144.124.16.6    dir.aber.ac.uk 
     v     ^      ttl   24        1/295  =  0%  32 pps     0/31   =  0%   3 pps
193.63.110.100  noc.bath.ja.net 
     v     ^      ttl   25       -1/294  =  0%  32 pps     0/31   =  0%   3 pps
193.63.104.100  noc.rl.ja.net  Output pruned
     v     ^      ttl   26        0/4    = --%   0 pps    31/31   =100%   3 pps
163.1.244.8     orac.physics.ox.ac.uk Prune sent upstream
     v     ^      ttl   27          4            0 pps       0            0 pps
163.1.32.155    plutonium.oucs.ox.ac.uk Prune sent upstream
     v      \__   ttl   28          0            0 pps       0            0 pps
163.1.32.155    163.1.32.155
  Receiver      Query Source

I assume that those pruning messages mean that because the upstream
routers failed to receive proper notification of the continuing group
membership, that the route was pruned back until the mtrace started up.

--Malcolm

-- 
Malcolm Beattie <[email-masked]>
Unix Systems Programmer
Oxford University Computing Services

---

From: [email-masked] (Alan Cox)
Date: Tue, 23 Jul 1996 15:45:30 +0100 (BST)

> to requests about group membership.

I assume you compiled the kernel with gcc 2.6.3 or later ? If so can you email
me a tcpdump of just the IGMP messages (I dont want a tcpdump of the video
conference!) over the 6 or 7 minutes to the freeze and I'll have a prod.

Alan