Re: PIM Convergence Problem

John,

Did you check the <*,G> for the particular group in question? Where is your
RP located? Where is the path to the RP? Did you look at the flags for the
output to "show ip mroute"? What was the output?

Without seeing your output, and outside of a bug (for normal behavior), its
likely that you were indeed having RPF failures for the <S,G> or source
tree, but were flowing down the shared tree. I've seen entries for the
<s,G> disappear from the output (even when the IGP or unicast table's path
to the source disappears from the RIB). The multicast tree still flows...
just via the shared tree.

A good indicator for how your getting your multicast (whether its from the
source tree or share tree) is simply to do a "show ip mroute count". And
look at the counters ..

Good luck.

On Sun, Apr 21, 2013 at 8:07 PM, John Neiberger <jneiberger_at_gmail.com>wrote:

> Yep. Sparse mode. We're using SSM for all of this multicast traffic. I
> suspect we ran into a bug or some corner case of "expected" behavior, but
> it seems pretty darn odd that the mroutes would continue to be joined on a
> path that fails RPF after a unicast routing change.
>
>
> On Sun, Apr 21, 2013 at 1:27 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> >wrote:
>
> > John,
> > you do have pim enabled all way around ? Sparse ? Dense ?
> > -Carlos
> >
> > John Neiberger @ 21/04/2013 14:56 -0300 dixit:
> > > That is what I suspect happened. For some reason, the mroute
> information
> > > stayed in place even though unicast routing had changed, which means
> > > that RPF had changed. A path that was no longer valid or usable was
> > > still being used to join multicast feeds. Usually, we see the mroutes
> > > switch immediately to follow the best unicast path, but that didn't
> > > happen this time and we're stumped as to why. The engineers working
> when
> > > it happened didn't clear any routes and didn't get any snapshots, so
> > > we're stuck with reverse engineering the scenario based on symptoms we
> > > observed. We can't really recreate it in production without causing
> > > noticeable problems for people, but we're going to try to recreate it
> in
> > > a lab environment. Cisco is going to try to recreate it in the lab, as
> > well.
> > >
> > >
> > > On Sun, Apr 21, 2013 at 11:25 AM, Tony Singh <mothafungla_at_gmail.com
> > > <mailto:mothafungla_at_gmail.com>> wrote:
> > >
> > > makes sense Carlos
> > >
> > > John if all else fails clear ip mroute * on the entire path as
> > > pointed out, what causes this maybe to do with stale mroute
> > > information not being flushed, check to see if you see this prior
> to
> > > doing this
> > >
> > > --
> > > BR
> > >
> > > Tony
> > >
> > > Sent from my iPad
> > >
> > > On 21 Apr 2013, at 12:24, Carlos G Mendioroz <tron_at_huapi.ba.ar
> > > <mailto:tron_at_huapi.ba.ar>> wrote:
> > >
> > > > Hmm,
> > > > I may be way off, because it is ages since I played with mcast
> last
> > > > time, but PIM does not run on top of the IGP/BGP session, it runs
> > > along
> > > > and uses the RIB for RPF. If you have pim enabled in the
> > > interfaces and
> > > > you tear down the BGP session, PIM does not care. After all, it
> is
> > > > independent of the routing protocol, isn't it ?
> > > >
> > > > -Carlos
> > > >
> > > > John Neiberger @ 20/04/2013 13:49 -0300 dixit:
> > > >> I posted this on cisco-nsp yesterday and didn't get any replies,
> > so I
> > > >> thought I'd run this past the group here.
> > > >>
> > > >> We ran into an interesting problem last night and I'm a little
> > > stumped. It
> > > >> appears that PIM did not follow a unicast routing change after a
> > > BGP peer
> > > >> was shutdown. Imagine this simple topology:
> > > >>
> > > >> [A] ----- [B] ------ [C] ------- [D]
> > > >> |
> > > >> |
> > > >> |
> > > >> [D]
> > > >>
> > > >> Router A is a CRS and is forwarding PIM joins toward Router D,
> > > which is
> > > >> directly attached. We are not running an IGP here. There is only
> > > an eBGP
> > > >> session between two ASes that we manage. We shutdown the BGP
> > session
> > > >> between A and D, which caused unicast traffic to switch to the
> > > path toward
> > > >> Router B. However, it looks like Router A did not tear down the
> > > PIM joins
> > > >> that are now no longer valid. It seems that it was still joining
> > > a lot of
> > > >> traffic that it could no longer do anything with since it would
> > > now fail
> > > >> RPF checks.
> > > >
> > > >
> > > > Rakesh M @ 21/04/2013 08:10 -0300 dixit:
> > > >> Hi,
> > > >>
> > > >> We had a similar issue with Juniper if my memory goes right. It
> > wont
> > > >> refresh until we manually give a clear command. Did you try
> > > clearing Pim ?
> > > >> Would everything get restored if you bring back the link between
> > > A and D ?
> > > >>
> > > >
> > > > --
> > > > Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> > > LW7 EQI Argentina
> > >
> > >
> >
> > --
> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Apr 23 2013 - 23:34:04 ART