From: NET HE (he_net@hotmail.com)
Date: Tue Feb 03 2009 - 01:06:12 ARST
Your understanding of QNS 2 and 3 is correct.
For QNS 1, the mechanism behind it is,
R3 (RP) is the source of 224.0.1.39 stream. And since the router R2 (hub) is
running on sparse-mode, it needs a RP to which it will send the 239.0.1.39
stream. But R2 doesn't know, so it drops the 239.0.1.39 stream. The same to
224.0.1.40, even though R2 (hub) receives join-message (*, 224.0.1.40) from R4
(MA), since R2 doesn't know any RP, it drops the join.
There is a walkaround, you can define a static RP for 224.0.1.39 and
224.0.1.40. Best Regards, Net (Xin) He > Date: Mon, 2 Feb 2009 17:34:29
+0100> Subject: Re: Multicast - NBMA> From: georgeroman@gmail.com> To:
nitrodrops@hotmail.com> CC: ccielab@groupstudy.com> > Hi Nitro> > a)ip pim
nbma-mode is used only for sparse-mode.> > b)The 224.0.1.39 and 224.0.1.40
groups are used in dense fashion.> > a) + b) = you need to tunnel in this
case> > > Best regards,> George> > On Wed, Jan 21, 2009 at 1:04 PM, Nitro
Drops <nitrodrops@hotmail.com> wrote:> > > Hi All,> >> > Have been practising
multicast by placing around RP and MA around in a> > Hub-N-Spoke.> >> > R3 -
Spoke1 > RP> > R2 - Hub> > R4 - Spoke2 > MA> >> > R3 s2/1 >> s2/1 R2 s2/1 >>
s2/1 R4> >> > Full Reachability using EIGRP.> >> > R2> > interface Serial2/1>
> ip address 155.8.10.2 255.255.255.0> > ip pim nbma-mode <<< included this> >
ip pim sparse-mode> > encapsulation frame-relay> > no ip split-horizon eigrp
1> > no ip mroute-cache> > frame-relay map ip 155.8.10.3 203 broadcast> >
frame-relay map ip 155.8.10.4 204 broadcast> > no frame-relay inverse-arp> >
!> > ip pim autorp listener> >> > R3 (RP)> > ip pim autorp listener> > ip pim
send-rp-announce Loopback0 scope 16> >> > R4 (MA)> > ip pim autorp listener> >
ip pim send-rp-discovery Loopback0 scope 16> >> >> > QNS 1 : I kept
encountering the announcement 224.0.1.39 from RP > MA got> > stuck> > at the
Hub, even though i have configured "ip pim nbma mode". Did i miss> > out> >
anything?> >> >> > P(0): s=150.8.3.3 (Serial2/1) d=224.0.1.39 id=299, ttl=15,
prot=17,> > len=52(48), mroute olist null> > IP(0): s=150.8.3.3 (Serial2/1)
d=224.0.1.39 id=322, ttl=15, prot=17,> > len=52(48), mroute olist null> >> >
l> > R2#sh ip mro> > IP Multicast Routing Table> >> > Outgoing interface
flags: H - Hardware switched, A - Assert winner> > Timers: Uptime/Expires> >
Interface state: Interface, Next-Hop or VCD, State/Mode> >> > (*, 224.0.1.39),
00:14:52/stopped, RP 0.0.0.0, flags: DC> > Incoming interface: Null, RPF nbr
0.0.0.0> > Outgoing interface list:> > Serial2/1, Forward/Sparse,
00:14:06/00:00:00> >> > (150.8.3.3, 224.0.1.39), 00:00:46/00:02:13, flags: PT>
> Incoming interface: Serial2/1, RPF nbr 155.8.10.3> > Outgoing interface
list: Null> >> > (*, 224.0.1.40), 00:15:04/00:02:18, RP 0.0.0.0, flags: DCL> >
Incoming interface: Null, RPF nbr 0.0.0.0> > Outgoing interface list:> >
Serial2/1, Forward/Sparse, 00:14:07/00:00:00> >> >> > QNS 2 : if all the 3
routers are running 'sparse-dense' mode, a tunnel will> > be> > required
between the spokes. Since 'ip nbma mode' is only supported on> >
'sparse-mode'> >> > QNS 3 : if all the 3 routers are running 'dense' mode, R3
(Server) R2> > (Client), again a tunnel will be required between the spokes,
since the> > incoming CANT be the same as the outgoing interface on the
multicast> > routing> > table.> >> >> > Cheers> > Nit> >> >
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:44:09 ARST