Re: PIM Convergence Problem

check all the IOS codes used in the path and check to see if their are any
bugs existing against this issue, I know re-creating the issue on gns3 isn't
emulating the hardware side of things but worth a shot, if these types os
issues keep you up at night like me ;)

--
BR
Tony
Sent from my iPad
On 21 Apr 2013, at 18:56, John Neiberger <jneiberger_at_gmail.com> wrote:
> 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> 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> 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>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net