From: Jian Gu (guxiaojian@gmail.com)
Date: Thu Apr 20 2006 - 04:03:43 GMT-3
Chris,
I can understand in your second scenario where every thing works.
In the first scenario (when PIM sparse mode is enabled on BB1), when
multicast is sourced from BB1 in this case, I think BB1 itself will act as
the first hop router and send register message to RP at R2(can you debug ip
pim on BB1 or R2 to confirm?), R6 will be transit router on the source tree.
What confused me is, how (S,G) is created on R6? any multicast entry on R6
should only be created when (S,G) join is initiated from R2 -- assuming
register process between BB1 and R2 is sucessful, but obviously the register
process is not successful. Also why BB1 is sending multicast to R6 while
R6's (*,G) and (S,G) olist are both null -- in this case BB1's olist should
all be pruned.
I would first double check RPF for RP and source IP addresses on each and
every router.
On 4/19/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
>
> Brian,
>
> I have a similar setup to Mohammed and this is what I see on my routers.
>
> Basically the config and sho ip mrout tables are exactly the same on my
> setup comapred to Mohammeds,
>
> If I have ip pim sparse mode configured on the s0/0 interface of BB1 I get
> the following debug from the R6 router
>
> *Mar 1 13:03:21.172: PIM(0): Check RP 150.1.2.2 into the (*, 228.28.28.28
> )
> entry
> *Mar 1 13:03:21.176: IP(0): s=54.1.2.254 (Serial0/0) d=228.28.28.28id=323,
> prot=1, len=104(100), mroute olist null
> *Mar 1 13:03:23.172: IP(0): s=54.1.2.254 (Serial0/0) d=228.28.28.28id=324,
> prot=1, len=104(100), mroute olist null
> *Mar 1 13:03:25.172: IP(0): s=54.1.2.254 (Serial0/0) d=228.28.28.28id=325,
> prot=1, len=104(100), mroute olist null
> *Mar 1 13:03:27.172: IP(0): s=54.1.2.254 (Serial0/0) d=228.28.28.28id=326,
> prot=1, len=104(100), mroute olist null
>
> Pings from BB1 fail
>
> Just taking ip pim sparse mode off BB1 gives me the fololwing debug from
> R6
>
> *Mar 1 12:59:09.912: PIM(0): Check RP 150.1.2.2 into the (*, 228.28.28.28
> )
> entry
> *Mar 1 12:59:09.916: PIM(0): Send v2 Register to 150.1.2.2 for 54.1.2.254
> ,
> group 228.28.28.28
> *Mar 1 12:59:09.916: IP(0): s=54.1.2.254 (Serial0/0) d=228.28.28.28id=318,
> prot=1, len=104(100), mroute olist null
> *Mar 1 12:59:09.920: PIM(0): Received v2 Join/Prune on FastEthernet0/0
> from
> 132.1.26.2, to us
> *Mar 1 12:59:09.920: PIM(0): Join-list: (54.1.2.254/32, 228.28.28.28),
> S-bit set
> *Mar 1 12:59:09.920: PIM(0): Add FastEthernet0/0/132.1.26.2 to (
> 54.1.2.254/32, 228.28.28.28), Forward state
> *Mar 1 12:59:11.472: PIM(0): Send v2 Null Register to 150.1.2.2
> *Mar 1 12:59:11.476: PIM(0): Received v2 Register-Stop on FastEthernet0/0
> from 150.1.2.2
> *Mar 1 12:59:11.476: PIM(0): for source 0.0.0.0, group 0.0.0.0
> *Mar 1 12:59:11.912: PIM(0): Send v2 Register to 150.1.2.2 for 54.1.2.254
> ,
> group 228.28.28.28
> *Mar 1 12:59:11.912: IP(0): s=54.1.2.254 (Serial0/0)
> d=228.28.28.28(FastEthernet0/0) id=319, prot=1, len=100(100), mforward
>
> Pings now work fine. This is repeatable (as long as you give everything
> enough time for the timeouts to settle after the change).
>
> Can you explain this? I am happy to paste a big reply with all my configs
> and the outputs you describe both with and without ip pim sparse mode on
> BB1
> to illustrate.
>
> Cheers
>
> Chris
>
>
> On 4/19/06, Mohammed Shameen Abdul Jabbar <ccie.xpert@gmail.com> wrote:
> >
> >
> > Brian,
> >
> > Thanks for your Input. I am referring to the IEWB scenario VER3.0, Lab
> 2,
> > Multicast task.
> > As per the requirements of the lab everything is working. But I have
> > enabled sparse-mode on the S0/0 interface of BB1 just for testing
> purpose ,
> > so that I can understand the concepts of Multicasting thoroughly. All
> the
> > Routers have unicast reachability to 54.1.2.245 ip of BB1 and All the
> > routers do know that R2 is the RP for the domain.
> >
> > I will post the configuration R2,R6 and BB1 as soon as i get back to my
> > lab.
> >
> > Chris, I will try out the options you provided as well.
> >
> > regards
> > shamin
> >
> > On 4/19/06, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
> > >
> > > This would not be the case since R6 has the (S,G) entry already
> > > installed. Looking just at the mrouting table of R6 my first guess
> > > would be that R6 isn't registering with the RP for that group. Also
> > > BB1's multicast configuration doesn't matter because it is a multicast
> > > source in this case, not a multicast router. Look at the "show ip pim
> > > rp mapping" output on all the pim routers. Do they know that R2 is
> the
> > > RP? Is the RPF check successful for traffic coming from and going to
> > > the RP? Do the rest of the multicast routers have a unicast route
> back
> > > to BB1? Paste the "show ip route" "show ip mroute" "show ip rp
> mapping"
> > > for all routers participating in multicast routing.
> > >
> > > HTH,
> > >
> > > Brian McGahan, CCIE #8593
> > > bmcgahan@internetworkexpert.com
> > >
> > > Internetwork Expert, Inc.
> > > http://www.InternetworkExpert.com <http://www.internetworkexpert.com/>
> > > Toll Free: 877-224-8987 x 705
> > > Outside US: 775-826-4344 x 705
> > > 24/7 Support: http://forum.internetworkexpert.com
> > > Live Chat: http://www.internetworkexpert.com/chat/
> > >
> > >
> > > > -----Original Message-----
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > > Of
> > > > Chris Lewis
> > > > Sent: Wednesday, April 19, 2006 8:09 AM
> > > > To: Vikram Dadlaney
> > > > Cc: ccielab@groupstudy.com; ccie.xpert@gmail.com
> > > > Subject: Re: Multicast problems
> > > >
> > > > It looks like you are using the physical interfaces for teh frame
> > > relay
> > > > connection between BB1 and R6. If so, I would have expected to see
> > > frame
> > > > relay map statements in those interfaces.
> > > >
> > > > You won't get multicast connectivity until unicast is working!
> > > >
> > > > Chris
> > > >
> > > >
> > > > On 4/19/06, Vikram Dadlaney <vdadlaney@gmail.com> wrote:
> > > > >
> > > > > Hi Shameen,
> > > > >
> > > > > From your topology it doesn't seem like you have any alternate
> > > paths.
> > > > Can
> > > > > you confirm this? Your OIL list on R6 is empty hence you are not
> > > > > forwarding
> > > > > the multicast traffic. Can you post the the configs of R2. Also
> have
> > > you
> > > > > tried clearing all your neighbors. The 'ip mroute' influences the
> > > RPF
> > > > > check.
> > > > > If you have multicast enabled on all interfaces than it should not
> > > > matter
> > > > > but say you have an alternate path and you haven't enabled
> multicast
> > > on
> > > > > that
> > > > > but the unicast routing table is choosing that path than you will
> > > have a
> > > > > RPF
> > > > > failure. Please do let us know if the problem has been resolved.
> > > HTH.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Vikram
> > > > >
> > > > >
> > >
> _______________________________________________________________________
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
> > >
> _______________________________________________________________________
> > > > Subscription information may be found at:
> > > > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:58 GMT-3