From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Fri Apr 21 2006 - 23:09:55 GMT-3
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 <mailto: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
<mailto: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 <mailto: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 <http://228.28.28.28/> ), 00:04:49/stopped, RP 150.1.2.2
<http://150.1.2.2/> , flags: SP
> Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
<http://132.1.26.2/>
> Outgoing interface list: Null
>
> (54.1.2.254 <http://54.1.2.254/> , 228.28.28.28 <http://228.28.28.28/> ),
00:04:49/00:01:17, flags: PT
> Incoming interface: Serial0/0, RPF nbr 0.0.0.0 <http://0.0.0.0/>
> Outgoing interface list: Null
>
> (200.1.1.1 <http://200.1.1.1/> , 228.28.28.28 <http://228.28.28.28/> ),
00:04:49/00:01:47, flags: T
> Incoming interface: Serial0/0, RPF nbr 54.1.2.254 <http://54.1.2.254/>
> Outgoing interface list:
> Ethernet0/0.26, Forward/Sparse, 00:04:50/00:02:36
>
> (*, 224.0.1.40 <http://224.0.1.40/> ), 00:07:51/00:02:57, RP 150.1.2.2
<http://150.1.2.2/> , flags: SJCL
> Incoming interface: Ethernet0/0.26, RPF nbr 132.1.26.2
<http://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 <http://224.0.1.40/> ), 00:44:11/00:00:00, RP 150.1.2.2
<http://150.1.2.2/> , flags: SJPCL
> Incoming interface: Serial0, RPF nbr 54.1.2.6 <http://54.1.2.6/>
> Outgoing interface list: Null
>
> (*, 228.28.28.28 <http://228.28.28.28/> ), 00:04:36/00:02:59, RP 150.1.2.2
<http://150.1.2.2/> , flags: SPF
> Incoming interface: Serial0, RPF nbr 54.1.2.6 <http://54.1.2.6/>
> Outgoing interface list: Null
>
> (200.1.1.1 <http://200.1.1.1/> , 228.28.28.28 <http://228.28.28.28/> ),
00:04:36/00:01:51, flags: FT
> Incoming interface: Loopback1, RPF nbr 0.0.0.0 <http://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 <http://228.28.28.28/>
>
> Type escape sequence to abort.
> Sending 1, 100-byte ICMP Echos to 228.28.28.28 <http://228.28.28.28/> ,
timeout is 2 seconds:
>
> Reply to request 0 from 132.1.0.3 <http://132.1.0.3/> , 160 ms
> Reply to request 0 from 132.1.17.7 <http://132.1.17.7/> , 264 ms
> Reply to request 0 from 132.1.0.3 <http://132.1.0.3/> , 220 ms
> Reply to request 0 from 132.1.17.7 <http://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