Re: PIM Convergence Problem

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
Received on Sun Apr 21 2013 - 18:07:40 ART