[3443] in linux-net channel archive
Re: MBONE offer
daemon@ATHENA.MIT.EDU (Malcolm Beattie)
Mon Jun 24 06:37:01 1996
From: Malcolm Beattie <malcolm.beattie@computing-services.oxford.ac.uk>
To: linux-net@vger.rutgers.edu
Date: Mon, 24 Jun 1996 11:25:15 +0100 (BST)
In-Reply-To: <199606240828.JAA01095@snowcrash.cymru.net> from "Alan Cox" at Jun 24, 96 09:28:39 am
Alan Cox writes:
>
> > (1) What gotchas with multicast under 2.0 should I look out for? Should
> > I run an earlier kernel instead? Does mrouted compile/work under 2.0?
>
> The Linux patched mrouted 3.6 seems to. I don't know about the 3.8 one.
>
> > (2) What sort of thing should I look for? I am more than happy to feed
> > my experiences back to the developers; all I need to know is what to
> > monitor. I tried to get the mbone running over the T1 at my old job and
> > never got it up, so this will be one of the ubiquitous learning
> > experiences that we hate so much.
>
> Do let me know what happens.
Good timing: I was just about to bring up mrouted on this mailing list
and someone else is jumping in too. I've been trying to set up a tunnel
with mrouted 3.81/Linux 2.0 and I'm having problems. The official end
point of the JANET mbone tunnel to Oxford is 163.1.244.8 (it's a class
B net subnetted to vlass C). I'm trying to set up a tunnel from there
to my host 163.1.32.155 on another subnet. I compiled mrouted 3.81 from
source having emoved the "Linux specific" header files (after verifying
that Linux 2.0 as exactly the same ones now). I've configured mroute
support into the ernel, along with other options that look as though
they might be needed:
#
# Networking options
#
# CONFIG_FIREWALL is not set
CONFIG_NET_ALIAS=y
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ACCT is not set
# CONFIG_IP_ROUTER is not set
CONFIG_NET_IPIP=m
CONFIG_IP_MROUTE=y
CONFIG_IP_ALIAS=y
# CONFIG_INET_PCTCP is not set
# CONFIG_INET_RARP is not set
# CONFIG_NO_PATH_MTU_DISCOVERY is not set
CONFIG_IP_NOSR=y
CONFIG_SKB_LARGE=y
My routing table is:
Kernel routing table
Destination Gateway Genmask Flags MSS Window Use Iface
localnet * 255.255.255.0 U 1500 0 14 eth0
loopback * 255.0.0.0 U 3584 0 2 lo
224.0.0.0 * 240.0.0.0 U 1500 0 13 eth0
default router32.oucs.o * UG 1500 0 32 eth0
My /etc/mrouted.conf looks like
tunnel 163.1.32.155 163.1.244.8 metric 1 threshold 24 rate_limit 500
The other end of the tunnel is running mrouted 3.8 under one of the more
recent versions of SunOS 4 (I'm not certain which). He initially had
kernel problems when trying to add a tunnel to me in addition to the
other two that he already runs: kernel messages
vmunix: ip_mforward: ip_mrouter socket queue full
forced him to reboot. On limiting his host to two tunnels (the official
one to/from Oxford and the one to me) and with my mrouted fired up with
"-p" to prevent pruning (just in case that caused problems) he no longer
gets kernel messages logged (I don't think) but my host is getting no
response from him at all. "mrouted -p -d 3" gives:
[~]plutonium# mrouted -p -d 3
debug level 3
11:18:16.062 mrouted version 3.8
11:18:16.100 Getting vifs from kernel interfaces
11:18:16.118 installing eth0 (163.1.32.155 on subnet 163.1.32/24) as vif #0 - rate=0
11:18:16.135 Getting vifs from /etc/mrouted.conf
11:18:16.155 installing tunnel from 163.1.32.155 to 163.1.244.8 as vif #1 - rate=500
11:18:16.171 Installing vifs in mrouted...
11:18:16.185 vif #0, phyint 163.1.32.155
11:18:16.201 SENT membership query from 163.1.32.155 to 224.0.0.1
11:18:16.218 SENT neighbor probe from 163.1.32.155 to 224.0.0.4
11:18:16.234 vif #1, tunnel 163.1.32.155 -> 163.1.244.8
11:18:16.250 SENT neighbor probe from 163.1.32.155 to 163.1.244.8
pruning off
11:18:16.274 Installing vifs in kernel...
11:18:16.318 vif #0, phyint 163.1.32.155
11:18:16.333 vif #1, tunnel 163.1.32.155 -> 163.1.244.8
vifs_with_neighbors = 0
Virtual Interface Table
Vif Name Local-Address M Thr Rate Flags
0 eth0 163.1.32.155 subnet: 163.1.32/24 1 1 0 querier
pkts in : 0
pkts out: 0
1 eth0 163.1.32.155 tunnel: 163.1.244.8 1 24 500
pkts in : 0
pkts out: 0
Multicast Routing Table (1 entry)
Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs
163.1.32/24 1 0 0 1*
11:18:21.349 ageing entries
11:18:21.352 SENT membership query from 163.1.32.155 to 224.0.0.1
11:18:21.355 SENT neighbor probe from 163.1.32.155 to 224.0.0.4
11:18:21.357 SENT neighbor probe from 163.1.32.155 to 163.1.244.8
11:18:26.349 ageing entries
11:18:31.349 ageing entries
11:18:31.352 SENT neighbor probe from 163.1.32.155 to 224.0.0.4
11:18:31.354 SENT neighbor probe from 163.1.32.155 to 163.1.244.8
11:18:36.349 ageing entries
11:18:41.349 ageing entries
11:18:41.352 SENT neighbor probe from 163.1.32.155 to 224.0.0.4
11:18:41.354 SENT neighbor probe from 163.1.32.155 to 163.1.244.8
11:18:46.350 ageing entries
and then just repeats without apparently hearing anything. Trying mtrace
which a random address on a different subnet gives:
[~]plutonium# mtrace 163.1.2.13
Mtrace from 163.1.2.13 to 163.1.32.155 via group 224.2.0.1
Querying full reverse path... IP data field too short (4 bytes) for IGMP from 163.1.32.155
* switching to hop-by-hop:
0 plutonium.oucs.ox.ac.uk (163.1.32.155)
-1 IP data field too short (4 bytes) for IGMP from 163.1.32.155
* IP data field too short (4 bytes) for IGMP from 163.1.32.155
* IP data field too short (4 bytes) for IGMP from 163.1.32.155
* Timed out receiving responses
Perhaps no local router has a route for source 163.1.2.13
Am I missing something obvious (like I did when I originally tried the
mbone without doing "route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0")
or is it really, as it initially seems, a problem at the other end of the
tunnel. I don't like the look of those "IP data field too short" messages.
--Malcolm
--
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services
