From: Tom Rogers (cccie71@yahoo.com)
Date: Sun Jun 13 2004 - 22:10:23 GMT-3
Thanks
Brian McGahan <bmcgahan@internetworkexpert.com> wrote:The RPF check is run against all multicast packets received by
the router, regardless if they are regular feeds or auto-rp
announcements. Whether the feed is using a shared tree or shortest path
tree does not affect whether the RPF check is run. It may however
impact whether or not the check passes, as the difference between the
shared tree and spt may impact the incoming interface for the feed.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Joe Chang
> Sent: Sunday, June 13, 2004 4:55 PM
> To: Richard Dumoulin; Tom Rogers; swm@emanon.com;
ccielab@groupstudy.com
> Subject: Re: PIM RPF intersting....
>
> 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"
> To: "Richard Dumoulin" ; "Tom Rogers"
> ; ;
> 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
]
> > 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 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
> >
> >
> >
> > -----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.
> >
**********************************************************************
---------------------------------
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:40 GMT-3