From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Wed Apr 19 2006 - 14:24:37 GMT-3
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.28 id=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.28 id=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.28 id=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.28 id=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.28 id=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
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:58 GMT-3