From: Hall, Keith (KHall@xxxxxxxxxxxxxxxxx)
Date: Tue Nov 14 2000 - 11:20:04 GMT-3
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
Keith T. Hall (E-mail).vcf
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:44 GMT-3