From: Tom Rogers (cccie71@yahoo.com)
Date: Sun Jun 13 2004 - 22:09:58 GMT-3
Thanx
Got the multicast in the right pocket :-) Now need to stuff the some of it on the left and then I ll be loaded :-)
Tom
Scott Morris <swm@emanon.com> wrote:
Ahhhhhhhhhhh!!! THAT is correct.
I wasn't reading his question in that fashion! But yes, because the mapping agent sends out messages via a multicast, there will be a RPF check on the receipt of that packet just like any other multicast!
I was reading the question as in a normal multicast SPF calculation whether the MA had anything to do with the equation or not, and the answer there is no.
:)
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
---------------------------------
From: Richard Dumoulin [mailto:richard.dumoulin@vanco.es]
Sent: Sunday, June 13, 2004 5:00 PM
To: Richard Dumoulin; Tom Rogers; swm@emanon.com; ccielab@groupstudy.com
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]
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
-----Original Message-----
From: 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