From: Brian (shotcaller30@xxxxxxxxxxx)
Date: Tue Nov 14 2000 - 17:11:10 GMT-3
I am not trying to make the other 2 routers join the group. I just want
them to be able to ping that multicast address and get a response.
Keith T. Hall wrote:
If I haven't explicitly "joined" a group or caused an incidental
registration somehow in the direction of the other router (ex. for another
downstream router), how can a automatically join all configured multicast
groups on the network? Isn't that Dense Mode PIM? Doesn't that defeat the
whole purpose of Sparse Mode PIM?
----- Original Message -----
From: Hall, Keith <KHall@greenwichtech.com>
To: <ccielab@groupstudy.com>
Sent: Tuesday, November 14, 2000 1:53 PM
Subject: RE: Repost: Multicast with RP as Spoke
> Good question! Let me pose one back to you... ;)
>
> In the case of r3-r2-r4 over NBMA from the scenario presented, r3 and r4
are
> going through the same r2 interface/subinterface with ip split-horizon
> disabled. If r3-r2-r4 use serial interfaces, these are different
interfaces
> - correct?
>
> In the non-NBMA mode, there is a clear line of traffic flowing
"downstream".
> In NBMA mode, there should be an explicit join to start the flow of
traffic.
>
> "[W]hen each join is received from NBMA neighbors, PIM stores each
neighbor
> IP address/interface in the outgoing interface list for the group. When a
> packet is destined for the group, the software replicates the packet and
> unicasts (data-link unicasts) it to each neighbor that has joined the
> group."
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_c
> /1cprt1/1cmulti.htm
>
> "[O]nly PIM WAN neighbors that have joined for the group will get packets
> sent to as data link unicasts"
>
>
http://www.cisco.com/warp/public/cc/techno/protocol/ipmu/prodlit/mcmds_an.ht
> m
>
> If I haven't explicitly "joined" a group or caused an incidental
> registration somehow in the direction of the other router (ex. for another
> downstream router), how can a automatically join all configured multicast
> groups on the network? Isn't that Dense Mode PIM? Doesn't that defeat
the
> whole purpose of Sparse Mode PIM?
>
>
> Keith T. Hall
> Sr. Network Engineer, Service Provider Accounts
> Greenwich Technology Partners
> 3810 Concorde Parkway, Suite 500
> Chantilly, VA 20151
> (703) 966-1854 Cell
> (703) 222-6465 Office
> (703) 222-6424 Fax
> khall@greenwichtech.com
> http://www.greenwichtech.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Brian
> Sent: Tuesday, November 14, 2000 12:47 PM
> To: cciemail
> Subject: Re: Repost: Multicast with RP as Spoke
>
>
> Well I don't believe the pruning is causing the problem. Try setting up
> between three routers connected by serial links without running it over a
> multipoint interface in the middle. You can ping from the one edge router
> to the other edge router which is the RP and has the join-group statement
on
> ite Ethernet port. Can anyone explain exactly what pim-nbma mode does,
> because it doesn't seem to work in this scenerio?
>
> Thanks
>
>
> ----- Original Message -----
> From: Hall, Keith <KHall@greenwichtech.com>
> To: <ccielab@groupstudy.com>
> Sent: Tuesday, November 14, 2000 9:20 AM
> Subject: RE: Repost: Multicast with RP as Spoke
>
>
> > RE: the lack of ping responses with 225.4.4.4 from r3 or 225.3.3.3 from
r4
> >
> > Jeez - I knew this Q would come up.. see pruning! ;)
> >
> > Remember that r4 and r3 are distant by a router hop. r4 is not
> subscribing
> > to 225.3.3.3 and r3 is not subscribing to 225.4.4.4 (and therefore I
> believe
> > it should be pruned under Sparse Mode PIM behavior - contrasted to Dense
> > Mode PIM behavior). The incidental responses received via r2 without
any
> > 'real multicast source' and any 'real multicast subscriber' present is
due
> > to proximity; not actual subscription.
> >
> > r3 ------- r2 ------- r4
> > 225.3.3.3 225.2.2.2 225.4.4.4
> >
> > Also, take a look at the overall design. In more complex scenarios,
this
> > can be quite a challenge to trace. Multicast pings are a little
different
> > from a standard unicast ping. 225.4.4.4 is on r4 (the RP). 225.4.4.4
is
> > figuratively "at the root of the tree" or "at the head of the waters",
so
> to
> > speak. (This is why I originally asked about the multicast source
> > placement.) Bad RP placement can have a very detrimental effect on the
> > multicast stream. Multicast implementation is very simple in small
> > networks, but can be a real pain in the @#$@ in larger ones. (In fact,
> I've
> > heard of only partially successful or unstable implementations by other
> > internetwork integration groups because of the lack of overall design
and
> > understanding of PIM mechanisms.)
> >
> >
> > RE: Multicast Example
> >
> > If I understand correctly, you are able to perform a multicast ping in
one
> > direction??? Check if the 'broadcast' keyword is on r3...
> >
> > Yesterday, I made up my own OSPF config to test your scenario. The
config
> > presented was definitely not a full config (ex. no 'frame-relay
> > interface-dlci' command) and I couldn't "cut-and-paste" it directly.
> > Judging by the complexity of the original config (route-maps, ODR, and
> > demand-circuit, et cetera), I would first try running the multicast
script
> I
> > sent over a simplified, standard OSPF over NBMA config without
route-maps
> or
> > other junk. Pls try this first..
> >
> >
> > Keith T. Hall
> > Sr. Network Engineer, Service Provider Accounts
> > Greenwich Technology Partners
> > 3810 Concorde Parkway, Suite 500
> > Chantilly, VA 20151
> > (703) 966-1854 Cell
> > (703) 222-6465 Office
> > (703) 222-6424 Fax
> > khall@greenwichtech.com
> > http://www.greenwichtech.com
> >
> >
> >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:45 GMT-3