All things related to multicast

[Philip Pishioneri <>]

[I'm resending this because: a copy has never been ACK'd to me, it
hasn't shown up in the web archives (sent Tuesday), and most
importantly, there was a typo in the subject ;-]

I have a problem with our external multicast connection that I'd like to
run by folks before I get further into debugging it. (Don't know if it's
related to cef or not.)

Synopsis: a connection to a group being sourced from outside our domain
doesn't feed continuously, but starts and stops in a cycle.  It'll
receive a feed for almost 3 minutes and then it'll stop for almost 4
minutes, and then repeat.

Details:  We're starting with an empty slate for multicast.  The
equipment is various Cisco boxes:

        - border router: GSR (IOS 12.0(10)S)
        - internal routers: 8540s (IOS 12.0(5)W5(13b))
        - switches (55xx's, 29xx's)

For the campus multicast domain, I'm trying to use just PIM V2 BSR. 
There's only one BSR candidate and one RP candidate during this initial
testing, and both are defined on one loopback interface on the GSR
border router.  CGMP is enabled on the switches.  The internal
interfaces are running sparse-dense mode.

The Abilene interface is the MSDP peer, configured according to their
web site cookbook.

If I connect to "Places all over the world" (or other announced group),
I'll receive all of the various sources for almost 3 minutes.  Then,
they'll all stop for almost 4 minutes.  And it repeats.

If I have another internal system source a stream into that group, it
does -not- exhibit this effect, and is received continuously while the
externals cycle.  (same is true if it is sourcing into a separate
group.)

If I have one receiver running, and it's not currently receiving, and I
start another receiver (on a separate subnet, different router), both
will start receiving until the latter's ~3 minute time is up, and then
they're synced to the same cycle.

I've read about the 3 minute PIM-SM interface timer, and figure that
this is expiring and causing interfaces to be pruned.  But since the
internal source keeps working, the (S,G) tree appears to be OK
internally, and the problem might be at the border.  I'm not certain how
the ~4 minute quiet time fits into this.

-Phil
Cornell University