It will take both the paths or else which path the multicast packet wll take
to reach the source
it cant take two paths
which path it will take
On Thu, Nov 18, 2010 at 8:05 PM, Marko Milivojevic <markom_at_ipexpert.com>wrote:
> It would be reflected back to R1.
>
> --
> Marko Milivojevic - CCIE #18427
> Senior Technical Instructor - IPexpert
>
> FREE CCIE training: http://bit.ly/vLecture
>
> Mailto: markom_at_ipexpert.com
> Telephone: +1.810.326.1444
> Web: http://www.ipexpert.com/
>
> On Thu, Nov 18, 2010 at 14:33, CCIE KID <eliteccie_at_gmail.com> wrote:
> > ok marko i understood ur point
> > So in ur scenario in the full mesh topology the loop happens
> > wat about this scenario
> >
> > s0/1
> > R1--------------------R2----------------------R3-
> > | fa0/1 |
> > | |
> > | |
> > |-------------------------|
> >
> >
> > In this scenario if in IGP there are two routes which R2 can reach R1
> > thorugh serial and fastetherent
> > In this case wat would be the multicast path
> > which path it would take if the packet comes from two paths
> >
> >
> > On Thu, Nov 18, 2010 at 7:54 PM, Marko Milivojevic <markom_at_ipexpert.com>
> > wrote:
> >>
> >> There is no RPF in that scenario and that's what would happen.
> >> However, with RPF, when each of the routers receives copy of the
> >> traffic from non-RPF interface, it will drop it.
> >>
> >> --
> >> Marko Milivojevic - CCIE #18427
> >> Senior Technical Instructor - IPexpert
> >>
> >> FREE CCIE training: http://bit.ly/vLecture
> >>
> >> Mailto: markom_at_ipexpert.com
> >> Telephone: +1.810.326.1444
> >> Web: http://www.ipexpert.com/
> >>
> >> On Thu, Nov 18, 2010 at 14:21, CCIE KID <eliteccie_at_gmail.com> wrote:
> >> > No marko can u be little more clear
> >> > wat is ur scenario deals wid RPF
> >> >
> >> >
> >> > On Thu, Nov 18, 2010 at 7:47 PM, Marko Milivojevic <
> markom_at_ipexpert.com>
> >> > wrote:
> >> >>
> >> >> A---B
> >> >> | X |
> >> >> C---D
> >> >>
> >> >> So, we have full mesh of connections between A, B, C and D. Source is
> >> >> attached to A. Source sends packet, A replicates it to B, C and D. C
> >> >> replicates the packet to B and D (B and D receive their 2nd copy of
> >> >> the same traffic). When B receives this traffic for C it replicates
> it
> >> >> to D (3rd copy), and back to A. A replicates it back to C, D... etc
> >> >> etc etc. You get the idea?
> >> >>
> >> >> --
> >> >> Marko Milivojevic - CCIE #18427
> >> >> Senior Technical Instructor - IPexpert
> >> >>
> >> >> FREE CCIE training: http://bit.ly/vLecture
> >> >>
> >> >> Mailto: markom_at_ipexpert.com
> >> >> Telephone: +1.810.326.1444
> >> >> Web: http://www.ipexpert.com/
> >> >>
> >> >> On Thu, Nov 18, 2010 at 14:10, CCIE KID <eliteccie_at_gmail.com> wrote:
> >> >> > Hey i know the RPF check happens every time when a multicast packet
> >> >> > comes to
> >> >> > router to check whether the same interface can be used to reach the
> >> >> > source
> >> >> > of the multicast feed.Why does this has been done?? To avoid
> >> >> > loops!!!!
> >> >> > *WHy
> >> >> > RPF check is mandatory for a multicast packet*?
> >> >> > If to avoid loops Can u give me a classic case of loop formation in
> >> >> > multicasting when RPF is not present
> >> >> >
> >> >> >
> >> >> > --
> >> >> > With Warmest Regards,
> >> >> >
> >> >> > CCIE KID
> >> >> > IN PURSUIT OF CCIE
> >> >> >
> >> >> >
> >> >> > Blogs and organic groups at http://www.ccie.net
> >> >> >
> >> >> >
> >> >> >
> _______________________________________________________________________
> >> >> > Subscription information may be found at:
> >> >> > http://www.groupstudy.com/list/CCIELab.html
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > With Warmest Regards,
> >> >
> >> > CCIE KID
> >> > IN PURSUIT OF CCIE
> >> >
> >
> >
> >
> > --
> > With Warmest Regards,
> >
> > CCIE KID
> > IN PURSUIT OF CCIE
> >
>
-- With Warmest Regards, CCIE KID IN PURSUIT OF CCIE Blogs and organic groups at http://www.ccie.netReceived on Thu Nov 18 2010 - 20:09:44 ART
This archive was generated by hypermail 2.2.0 : Sun Dec 05 2010 - 22:14:56 ART