From: Jian Gu (guxiaojian@gmail.com)
Date: Thu Apr 20 2006 - 04:29:27 GMT-3
Can you post "sh ip rpf 200.1.1.1" and "sh ip rpf 54.1.2.254" on R2?
On 4/20/06, Shamin <ccie.xpert@gmail.com> wrote:
>
> Chris,
>
> I wonder how I will master this topic on multicast.
> Now something interesting happened, In the process of doin what you
> had requested, just as a trial and error method i enabled "ip pim
> sparse-mode" on the loopback 1 interface of BB1. And i was able to get
> a reply.
>
> I will paste the output of sh ip mroute on R6
>
>
> Rack1R6#sh ip mroute
> IP Multicast Routing Table
>
> (*, 228.28.28.28), 00:04:49/stopped, RP 150.1.2.2, flags: SP
> Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
> Outgoing interface list: Null
>
> (54.1.2.254, 228.28.28.28), 00:04:49/00:01:17, flags: PT
> Incoming interface: Serial0/0, RPF nbr 0.0.0.0
> Outgoing interface list: Null
>
> (200.1.1.1, 228.28.28.28), 00:04:49/00:01:47, flags: T
> Incoming interface: Serial0/0, RPF nbr 54.1.2.254
> Outgoing interface list:
> Ethernet0/0.26, Forward/Sparse, 00:04:50/00:02:36
>
> (*, 224.0.1.40), 00:07:51/00:02:57, RP 150.1.2.2, flags: SJCL
> Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
> Outgoing interface list:
> Serial0/0, Forward/Sparse, 00:07:28/00:03:00
>
>
*****************************X******************************X****************
***************
>
> Multicast routing table on BB1:
>
> BB1#sh ip mroute
> IP Multicast Routing Table
>
> (*, 224.0.1.40), 00:44:11/00:00:00, RP 150.1.2.2, flags: SJPCL
> Incoming interface: Serial0, RPF nbr 54.1.2.6
> Outgoing interface list: Null
>
> (*, 228.28.28.28), 00:04:36/00:02:59, RP 150.1.2.2, flags: SPF
> Incoming interface: Serial0, RPF nbr 54.1.2.6
> Outgoing interface list: Null
>
> (200.1.1.1, 228.28.28.28), 00:04:36/00:01:51, flags: FT
> Incoming interface: Loopback1, RPF nbr 0.0.0.0, Registering
> Outgoing interface list:
> Serial0, Forward/Sparse, 00:04:36/00:02:50
>
>
**********************************X******************************X***********
***********
>
> Ping output on BB1:-
>
> BB1#ping 228.28.28.28
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 228.28.28.28, timeout is 2 seconds:
>
> Reply to request 0 from 132.1.0.3, 160 ms
> Reply to request 0 from 132.1.17.7, 264 ms
> Reply to request 0 from 132.1.0.3, 220 ms
> Reply to request 0 from 132.1.17.7, 176 ms
>
> This is turning out to be very confusing. Why do I get a reply when i
> enable "Ip pim sparse-mode" on another interface. Another point to
> note is, All the routers i pinged from and on which i got reply from
> the multicast group had more than 1 interfaces which had "Ip pim
> sparse-mode" enabled. But on BB1 i had it enabled only on the
> interface which was connected to R6. When I enabled a second interface
> on sparse-mode, it started working. Well, I cant really get to reason
> why this happened.
>
> Any inputs?
>
> regards
> shamin
>
>
>
**********************************X**********************************X*******
***************
>
> On 4/20/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
> > Mohammed,
> >
> > Good, so you tried one thing and saw that it fixed the problem, so the
> next
> > thing to figure out is why.
> >
> > The initial problem is the olist on R6 was empty. Putting the join on
> the
> > ethernet of R2 sends a join directly to R6 and creates an entry in the
> > olist, so it is no longer empty and BB1 can get it packets forwarded
> > through
> > R6. Using the igmp helper from the R3 side of R2 achieves much the same
> > thing, in terms of getting an entry in the olist of R6.
> >
> > However, these are workarounds, they are not fixing what is really
> broken
> > with the setup you have.
> >
> > When a source starts sending, the first multicast router to receive that
> > mutlicast packet in a sparse mode network will encapsulate the multicast
> > packet with a unicast header addressed to the RP. This process is known
> as
> > the PIM register process.
> >
> > If you get rid of the extra joins and helpers and get back to the
> original
> > configuration when BB1 cannot ping the group, you should see that taking
> > PIM
> > off the BB1 interface enables pings to happen, now the question is why?
> Why
> > can R6 now register the source with the RP? Think about which router can
> > send the register packets on the multi-access network between BB1 and
> R6?
> > You see this by looking at the output of the sho ip pim neighbor command
> on
> > BB1 or R6. Then think about why that router is not sending a register
> > packet. If you can answer this, you'll know why the setup was not
> working
> > originally and how you can get it working.
> >
> > Let us know how your investigation goes.
>
> _______________________________________________________________________
> 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