Subject: Solaris mrouted & Cisco/pruning

From: [email-masked] ( Edman Burr )
Date: Thu, 12 Jun 97 14:28:59 BST

I'm currently (still) trying to get a working MBone feed. My ISP is supplying
a tunel from a Cisco over a dial-up ISDN link. I'm used mrouted 3.8 on a Sun
IPX running Solaris, with the latest multicast patch from Sun.

When I start a PPP seesion and bring up mrouted the link saturates with mbone
traffic, but no sessions are pruned back. I've confirmed this by checking 
entries in the mrouted.cache file. I see occasional packets on the SDR group, 
but no sessions show up in SDR.

Something I've noticed, which is possibly irrelevant, is that I don't receive
any DVMRP probe packets from the Cisco at the ISP. A line in the DVMRP draft
caught by attention:

  When sending a prune upstream the following steps should be taken: 1. Decide
  if the upstream neighbour is capable of receiving prunes.

As far as I can see there are no mechanisms apart from probe packets which could
carry information about a DVMRP router's prune capability. Am I right? Could
this be a part of my problem? The Cisco router is ont unaware of my mrouter, it
lists my subnet in its route report packets.

Another thing in DVMRPv3, Section 12/Appendix C:

      Implementations prior to this specification may not wait to send
      route reports until probe messages have been received with the
      routers address listed. Reports SHOULD be sent to these neighbors
      without first requiring a received probe with the routers address
      in it as well as reports from these neighbors SHOULD be accepted.
      Although, this allows one-way neighbor relationships to occur, it
      does maintain backward compatibility.

reinforced my guess that a full neighbour relationship might not be established 
between the two tunnel endpoints.

Any suggestions would be most welcome... Thanks, Ed.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 12 Jun 1997 10:14:21 PDT

[email-masked] ( Edman Burr ) wrote:
>entries in the mrouted.cache file.

Does that mean that the mrouted.cache doesn't have a P next to the
incoming interface, or that the mrouted.cache has a P but the Cisco
doesn't stop sending you traffic?

>any DVMRP probe packets from the Cisco at the ISP.

Yes, it's irrelevant.  Route report packets contain the same information
as Probe packets with respect to capabilities.

The two things to check are:
1. The DVMRP router lists the Cisco as the parent of all the sources
in mrouted.dump for which you're receiving traffic from the Cisco.
2. Any downstream DVMRP routers have sent a prune to this one. (check
mrouted.cache for lowercase p's on outgoing interfaces).

You can see if there are any downstream neighbors by checking "mrinfo"
or look in the first section of mrouted.dump for "peers:".

If you see a bunch of entries in the mrouted.cache with a incoming
vif of -1, and which have /32 routes listed in mrouted.cache, make
sure that the Cisco is sending you DVMRP routes for all the sources
that it's sending you; if there is no DVMRP route for traffic then
mrouted doesn't know where to send a prune.  The command "ip dvmrp
default-information originate" could be useful here, but make sure
that you can't leak the default route to the MBone at large (e.g.
don't use this command when you have redundancy in your topology)

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Thu, 12 Jun 1997 13:07:59 PDT

Bill Fenner <[email-masked]> wrote:
>The command "ip dvmrp default-information originate" could be useful here

It's been pointed out that I probably meant to say
"ip dvmrp default-information only".  "... originate" will work
but the routing table will have extra unnecessary routes in it.
"... only" tells the Cisco to *only* send the DVMRP default
route and is the appropriate choice for a singly-connected
subtree.

  Bill