From: Shamin (ccie.xpert@gmail.com)
Date: Fri Apr 21 2006 - 13:23:48 GMT-3
Chris,
I went through the DR related topics. I got the command, "Ip pim
dr-priority" from the command refernce of IOS12.3. I could configure this on
R6 . I made the DR priority to 200 on R6 but that did not change the DR
election at all. I belive the default priority is 1. I think this might be
due to the reason that I am using IOS12.1 on BB1 which is a Cisco2500
router. I will try it with a 12.2 IOS and see the outcome.
regards
shamin
On 4/21/06, Chris Lewis <chrlewiscsco@gmail.com> wrote:
>
> 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