Subject: mtrace and mrouted3.9b

From: Tiziana Ferrari <[email-masked]>
Date: Tue, 7 Oct 1997 10:28:32 +0200 (MET DST)

I've installed succesfully mrouted3.9b on a SOlaris 2.5.1 box, I didn't
notice any bug so far, I've only encountered a strange problem: when I try
to use mtrace I get the following output:

astra.SunOS_5.5.1> mtrace mae-bone.psi.net
mtrace: WARNING: no multicast group specified, so no statistics printed
Mtrace from 192.41.177.247 to 192.135.23.2 via group 224.2.0.1
Source & receiver are directly connected, no path to trace
astra.SunOS_5.5.1>

this is obviously wrong, and I also get the same when I supply any 
host name, also hosts which don't act as mrouter and are not connected to
the MBONE.
From your point of view, can this problem be due to mrouted3.9b or did I
simply do anything wrong?
Thanks in advance for your help,
Tiziana Ferrari

PS: before the same box was running mrouted3.8 and mtrace always worked
correctly.

On Fri, 6 Jun 1997, Bill Fenner wrote:

> Hi,
> 
>   I'm happy to announce a public beta test of mrouted 3.9 .  mrouted 3.9
> has been over two years in the making, and I learned some very difficult
> software engineering lessons during that time.  mrouted 3.9 does *not*
> have the route aggregation feature that so many people want, due to said
> software engineering lessons.  That feature is still in the works but
> I thought it was more important to solve some of the more pressing
> pruning-related problems that people are having.
> 
>   This version of mrouted is *much* better about pruning for a couple of
> reasons:
> - mrouted 3.8 would arbitrarily forget about prunes at random times.
>   mrouted 3.9 keeps better track of prunes.
> - mrouted 3.9 retransmits prunes by default on point-to-point links
>   (configurable on multi-access links with the "rexmit_prunes" configuration
>   file entry), which takes care of both when prunes are lost and when
>   your neighbor forgets about prunes like mrouted 3.8 does.
> It also fixes mrouted 3.8's problem of wanting to receive prunes from
> all neighbors and only requires prunes from subordinate neighbors.
> 
>   The default prune lifetime is now settable separately from the kernel
> cache lifetime and defaults to 2 hours as specified by the current
> DVMRP internet-draft.  HOWEVER, since Cisco's IOS currently does not
> use DVMRP's generation ID feature which allows discovery of a router
> reboot, prunes sent to an IOS neighbor will last across reboot
> (potentially causing black holes for those sources and groups until the
> prunes time out).  When the default was 5 minutes, this wasn't a
> problem, but with the longer default, this could potentially be a
> problem.  Therefore, I recommend putting "prune_lifetime 300" on any
> vif's (phyints or tunnels) connecting to a Cisco to set the lifetime
> back to 5 minutes for prunes sent in that direction until this bug is
> fixed.
> 
>   It also includes limited route filtering, passive tunnels, configurable
> startup flooding, and other features.  Its basic functionality has been
> tested on DARTNet/CAIRN and by several alpha-testers.  This is a very
> stable beta; it's a beta not because of known bugs but mostly because of
> missing features and polishing.  I'd like to see providers trying out
> incoming route filtering from customers, and people trying out the longer
> prune lifetimes & retransmissions.
> 
>   Unfortunately, the SNMP modifications are not included, as although
> Dave Thaler tried to keep up with my changes, I managed to keep ahead
> and the SNMP stuff hasn't caught up yet.  The SNMP stuff should be
> integrated soon.
> 
>   Please try mrouted-3.9-beta1, and send me feedback about how you are
> using it and how it performs.
> 
> Thanks,
>   Bill
> 
> [Release notes appended]
> 
> $Id: README-3.9-beta1.mrouted,v 3.2 1997/06/06 21:43:23 fenner Exp $
> 
>         IP Multicast Extensions for BSD-Derived Unix Systems
>         Multicast Routing Daemon
> 
>         Release 3.9-beta1
>         May 31, 1997
> 
>         available from parcftp.xerox.com,
>         file pub/net-research/ipmulti/beta-test/mrouted3..9-beta1.tar.Z
>         binaries:
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-sparc-sunos41x.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-sparc-solaris2.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-i386-bsd.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-alpha-osf1.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-sgi-irix5.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-sgi-irix6.tar.Z
>         pub/net-research/ipmulti/beta-test/mrouted3.9-beta1-hp-hpux.tar.Z
> 
> Note: The 3.9 release is mrouted-only, and will run on top of a 3.5 kernel.
> It is a drop-in replacement for mrouted 3.5, 3.6, 3.7 or 3.8.
> 
> NOTE WELL: This is a beta-test release of mrouted.  The basic
> functionality has been extensively tested in DARTNet and other
> testbeds, but it is expected to have bugs.  Please report bugs to Bill
> Fenner <[email-masked]>.
> 
> The 3.9-beta1 release has the following known bugs:
> 
>   o The startup message doesn't print properly if you have too many
>     interfaces.
> 
> The 3.9-beta1 release fixes the following bugs:
> 
>   o mrouted did not properly keep track of subordinates, and would not
>     time out subordinateness.  This caused 2 major problems:
>     1. pruning did not happen when there were equal-cost paths to
>        the same multi-access link
>     2. subordinateness which did not get cancelled by a non-poisoned
>        route (e.g. in the face of route filtering) did not time out,
>        causing traffic to continue to flow.
> 
>   o mrouted's IGMPv2 processing when it is not the querier now
>     conforms to draft-ietf-idmr-igmp-v2-06.txt Thanks to Lorenzo
>     VICISANO <[email-masked]> for finding a problem.
> 
>   o mrouted is much more careful about forgetting prunes; 3.8
>     would forget prunes whenever any route change ocurred.
> 
> The 3.9-beta1 release has the following new features:
> 
>   o Longer prune lifetimes (2 hours) by default.  Prune lifetimes may
>     be configured per-vif, with the "prune_lifetime N" mrouted.conf
>     configuration file entry (where N is in seconds).  This helps to
>     work around the black holes caused on restart when you have a Cisco
>     upstream which does not handle genid's; if this is your situation
>     the recommended value is 300.
> 
>   o mrouted's behavior of flooding by default can be turned off
>     per-vif or globally with the "noflood" configuration option.
> 
>   o mrouted now retransmits prunes by default on point-to-point links.
>     prune retransmission can be turned on or off per vif via the
>     "rexmit_prunes [on|off]" mrouted.conf command.  Prune retransmission
>     helps on lossy links, and also helps when a router has forgotten
>     about a prune (e.g. if it is out of memory and needs to shed state,
>     or due to a bug).
> 
>   o The new "passive" mode causes mrouted to not actively send probes
>     looking for neighbors.  This allows a dialup link to become quiescent
>     if there is no DVMRP neighbor on the other end.  Configuring
>     "passive" on both ends of a link will cause it to never come up.
> 
>   o mrouted defaults to not peering with DVMRP routers that do not
>     prune.  Use the "allow_nonpruners" mrouted.conf option on a vif
>     on which you want to allow such peerings.
> 
>   o mrouted now allows route filtering.  mrouted.conf syntax:
>         accept 13/8
> 
>         accepts all routes matching 13/8 (e.g. accepts
>         13.2.116/22).  If you want to accept only exactly
>         13/8, use
> 
>         accept 13/8 exact
> 
>         deny 10/8 64/2 130/8 exact 172/8 exact
> 
>         denies some common MBone martians
> 
>       Only "accept" or "deny" is allowed, no combinations.
> 
>       Add "bidir" to apply the filter to output too, otherwise
>       it's input only.
> 
>     Expected usage:
>     - Providers filter routes that customers send them
>     - Martian removal
>     - Topology modification (e.g. don't let the existence of
>     private tunnel foo out into the world).
> 
> 
>   o mrouted now malloc's the buffer it uses for SIOCGIFCONF, to allow
>     for more interfaces.  Thanks to Danny Mitzel
> 
>   o mrouted now ignores multiple entries for a single interface
>     name (temporary hack until mrouted understands interface aliases)
> 
>   o mrouted's "-d" flag has been modified to accept the names of the
>     systems which you would like to debug.
>     packet, prunes, routes, peers, cache, timeout, interface,
>     membership, traceroute, igmp
> 
>   o mrouted now times neighbors out fater, and fully detects and
>     ignores routes from one-way peerings.
> 
>   o mrouted's route processing has been sped up, especially at startup.
> 
>   o mrouted uses the biggest SO_RCVBUF the operating system allows
>     (up to 256Kbytes)
> 
>   o mrouted uses TOS 0xc0 ("Internet Control") for DVMRP messages.
>

---

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Oct 1997 09:13:07 PDT

Could you run mrouted with "-d mtrace" and see what mrouted's debugging
messages say when you try the mtrace?

Thanks,
  Bill

---

From: Tiziana Ferrari <[email-masked]>
Date: Tue, 7 Oct 1997 20:34:07 +0200 (MET DST)

> messages say when you try the mtrace?
The message I get is the following:

20:26:08.258 ignoring unknown IGMP message type 0 from 127.0.0.1 to
127.0.0.1

Thanks a lot,
Tiziana