From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Thu Apr 20 2006 - 11:05:10 GMT-3
Jian and Mohammed,
Forget about RPF, it is not relevant to this case.
What is relevant to this case is the PIM sparse process, how sources get
registered with the RP and which router on a multi-access segment has the
responsibility for registering a source with the RP. I do find the Doyle II
book useful here and recommend you study it also.
You also need to be comfortable with the way ping works when you send to a
multicast address. It basically sends the ping packet out all interfaces
(including loopbacks).
Jian with PIM sparse on the S0/0 of BB1, BB1 is indeed responsible for
sending register messages. You need to know why that is the case. You also
need to know that BB1 is not teh first hop router in this case, it is merely
generating a ping to a multicast address out all interfaces. So there is a
disconnect here in terms of who is responsible for sending the registers and
who is the first hop router. You need to understand the concept of the PIM
DR, which router becomes the PIM DR on a multi-access segment, why BB1
thinks he is it and how you change it to be R6. Obviously taking PIM sparse
off of BB1 accomplishes that, but there is an ip pim command you canput on
the interface of R6 to make that the DR (enough clues :).
Mohammed, if you follow the above to Jian you should be able to answer your
questions.
Chris
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.
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:58 GMT-3