From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Fri Apr 21 2006 - 10:18:52 GMT-3
Anything is possible in software, but that's not the way it works.
When a router is originating a ping, it does just that, it sends out the
packet. Multicast routing decisions are taken on receipt of a packet. This
is the way it works, if you want to suggest a re-write of all multiacst
routing it will be a challenge to say the least :)
Chris
On 4/20/06, Jian Gu <guxiaojian@gmail.com> wrote:
>
> Chris,
>
> Thanks for the explanation, I did have misunderstanding of DR and register
> process. So change DR priority on R6 can make R6 as DR, but still I don't
> understand why making BB1 DR (by default) won't work in this case? Are you
> saying that when BB1 is a multicast source it won't be able to act as DR
> role at the same time? Since ping packets are processed by CPU I don't see
> any reason why IOS can not "recirculate" the packets it generated by
> encaping them and then send to RP.
>
>
> Jian
> On 4/20/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
>
> > 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.
>
> _______________________________________________________________________
>
> 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