From: Joe Chang (changjoe@earthlink.net)
Date: Sun Jun 13 2004 - 18:54:56 GMT-3
That's because each MA and all PIM nodes communicate via a dense mode
shortest path tree. This should all be set up prior to the RPF checking of
packets coming from SPT or switched-over shortest path trees.
----- Original Message -----
From: "Richard Dumoulin" <richard.dumoulin@vanco.es>
To: "Richard Dumoulin" <richard.dumoulin@vanco.es>; "Tom Rogers"
<cccie71@yahoo.com>; <swm@emanon.com>; <ccielab@groupstudy.com>
Sent: Sunday, June 13, 2004 4:59 PM
Subject: RE: PIM RPF intersting....
> See below. R1 is not taking the rp discoveries sent by the mapping agent
> because of RPF failure !
>
> Rack1R1#sh ip pim
> *Mar 1 09:26:40.287: IP(0): s=150.1.4.4 (Serial0/1) d=224.0.1.40 id=339,
> prot=17, len=52(48), RPF lookup failed for source
> *Mar 1 09:26:40.287: IP(0): s=150.1.4.4 (Serial0/1) d=224.0.1.40 id=339,
> prot=17, len=52(48), not RPF interface
> Rack1R1#sh ip pim
> *Mar 1 09:26:42.291: IP(0): s=150.1.4.4 (Serial0/1) d=224.0.1.39 id=341,
> prot=17, len=52(48), RPF lookup failed for source
> *Mar 1 09:26:42.295: IP(0): s=150.1.4.4 (Serial0/1) d=224.0.1.39 id=341,
> prot=17, len=52(48), not RPF interface
> Rack1R1#sh ip pim rp map
> PIM Group-to-RP Mappings
>
> --Richard
>
> -----Original Message-----
> From: Richard Dumoulin
> Sent: domingo, 13 de junio de 2004 22:43
> To: Tom Rogers; swm@emanon.com; ccielab@groupstudy.com
> Subject: RE: PIM RPF intersting....
>
>
> I don't think so. We have to check that no RPF failure exist between the
> RP's and the MA's and the MA's and all mulicast routers,
>
> --Richard
>
> -----Original Message-----
> From: Tom Rogers [mailto:cccie71@yahoo.com <mailto:cccie71@yahoo.com> ]
> Sent: domingo, 13 de junio de 2004 22:14
> To: swm@emanon.com; ccielab@groupstudy.com
> Subject: RE: PIM RPF intersting....
>
>
> Scott,
> So MA agent is not to of any concern? We can ignore it?
> Only ips that we should care about is the ip address's of RP and Source?
>
> Thanks
> Tom
>
> Scott Morris <swm@emanon.com> wrote:
> If you are looking for the shortest path tree, you are comparing the
> multicast source IP to the RP address (mapping agent only tells you where
> the RP is, other than that, you don't care).
>
> So those two specific things are looked at, and only that. The router will
> automagically do these things.
>
> You can use the ip pim spt-threshold command to tweak this performance as
> well.
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
> JNCIP, et al. IPExpert CCIE Program Manager IPExpert Sr. Technical
> Instructor swm@emanon.com/smorris@ipexpert.net
> http://www.ipexpert.net <http://www.ipexpert.net>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com
> <mailto:nobody@groupstudy.com> ] On Behalf Of Tom Rogers
> Sent: Sunday, June 13, 2004 3:12 PM
> To: ccielab@groupstudy.com
> Subject: PIM RPF intersting....
>
> Hi all,
>
> I have a question. Again a very stupid one :-) We know that we need to
look
> out for RPF aka the split horizon issue in multicasting. We need to make
> sure multicast stream is coming from the unicast routing table interface
or
> else we point mroute to the interface configured for PIM mode.
>
> If it is a Source bases (default) I ll look for source's (media server) ip
> address If it is a Shared tree, I ll lookout for RP's ip address.
>
> Q1) Should we, also be looking out for Mapping agent'a ip address also?
> Q2) Do we have to lookout for Source and RP addresses at the same time?
Coz
> intially it is Shared and then it switches to source (default)
>
> Thanx
> Tom
>
>
> ---------------------------------
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger
>
>
>
> **********************************************************************
> Any opinions expressed in the email are those of the individual and not
> necessarily the company. This email and any files transmitted with it are
> confidential and solely for the use of the intended recipient. If you are
> not the intended recipient or the person responsible for delivering it to
> the intended recipient, be advised that you have received this email in
> error and that any dissemination, distribution, copying or use is strictly
> prohibited.
>
> If you have received this email in error, or if you are concerned with the
> content of this email please e-mail to: e-security.support@vanco.co.uk
>
> The contents of an attachment to this e-mail may contain software viruses
> which could damage your own computer system. While the sender has taken
> every reasonable precaution to minimise this risk, we cannot accept
> liability for any damage which you sustain as a result of software
viruses.
> You should carry out your own virus checks before opening any attachments
to
> this e-mail.
> **********************************************************************
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:40 GMT-3