[3828] in linux-net channel archive
Linux: mrouted now OK, group timeouts happening
daemon@ATHENA.MIT.EDU (Malcolm Beattie)
Wed Jul 24 06:45:56 1996
From: Malcolm Beattie <malcolm.beattie@computing-services.oxford.ac.uk>
To: mbone@isi.edu, linux-net@vger.rutgers.edu, iialan@iifeak.swan.ac.uk
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 <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
