From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Sat Apr 22 2006 - 13:57:46 GMT-3
Dave, please read previous posts on this thread,
The PIM DR is automatically assigned, however that is the problem with
Mohammed's setup. BB1 is the DR as it has the highest IP address. The DR is
responsible for sending register messages, however the first multicast
router to receiv a multicast packet is R6 and that is not the DR, so it
can't send a register and BB1 never gets identified as a source at the RP.
The strangeness with this one is that BB1 is emulating a multicast source
(which does not normally participate in multicast routing), but BB1 itself
is a PIM device.
Chris
On 4/21/06, Schulz, Dave <DSchulz@dpsciences.com> wrote:
>
> Is it necessary to manipulate the DR-priority, as long as you keep the
> mapping agent at the hub. I thought that this was something that would be
> automatically assigned. Is this true or not.
>
> Dave
>
> ------------------------------
> *From:* Shamin [mailto:ccie.xpert@gmail.com]
> *Sent:* Fri 4/21/2006 12:23 PM
> *To:* Chris Lewis
> *Cc:* Jian Gu; Nick Griffin; Schulz, Dave; Vikram Dadlaney;
> ccielab@groupstudy.com
> *Subject:* Re: Multicast problems
>
>
> 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