Re: hi

Hi Sameer,

Are you talking about the "Source Active" message?

On Mon, Aug 3, 2009 at 12:07 AM, Darby Weaver <ccie.weaver_at_gmail.com> wrote:

> Sameer,
>
> Let me know if you like my format. If I made mistakes and anyone catches
> let me know too please. Anyway, this was from a post a made a week or two
> ago to start trying to pound what I know and how I actually think about
> multcast "real-time".
>
> Notice in this segment I'm answering the "Who is the source" question and
> the sme technique carries over to the other variants of multicast too but
> hey I had to start somewhere.
>
>
>
>
> On Mon, Aug 3, 2009 at 12:05 AM, Darby Weaver <ccie.weaver_at_gmail.com>
> wrote:
>
> > Let's talk about Multicast (MCAST)!
> >
> > Multicast Distribution Trees - This is the root of the shared tree.
> >
> > PIM Neighbors - PIM is the language of MCAST we care about for the CCIE
> > Lab. So let's not waste much time.
> >
> > Routing Protocols - We need a path (RPF Check)
> >
> > Neighbors - We need to know where to send or receive a MACST packet from.
> >
> > Source - We need to know where the packet came from.
> >
> >
> > There it is folks... Black and White.
> >
> > Who: As in "Who is the source?"
> >
> > Where: As is "Where is the neighbor?"
> >
> > RPF Check: As in "Where is the source and how do I know which PIM enabled
> > interface to send the MCAST packet to in order to get there?"
> >
> >
> > Let's talk about PIM Mode:
> >
> > 1. Any Source Multicast (ASM)
> >
> > - PIM-SM
> > - Supports both shared and source trees.
> >
> > 2. Source-Specific Multicast (SSM)
> >
> > - Single Source Multicast (Hint: We are being specific here).
> > - Supports only Source Trees (No need for RP's, RP Failover, etc.)
> >
> > 3. Bi-directional PIM (Bidir-PIM
> >
> > - Supports only shared trees.
> >
> >
> > Here's a quick and simple process.
> >
> > Computer A wants to subcribe or join a mulicast feed.
> >
> > So...
> >
> > Computer A makes an assumption that Router A: knows the RP, has the RP in
> > its RIB via an IGP with Router B, and has a neighbor relationship with
> > Router B. It is further assumed that Router B shares similar assumptions
> for
> > each router in the path to the RP (which might actually be on any router
> in
> > the path).
> >
> > So I guess we have some questions...
> >
> > If router A send a PIM (*,G) "Join" out what is really happening anyway?
> >
> > 1. Sending a PIM 224.0.0.13 to all PIM Routers - Kewl.
> >
> > - Note there are like 5 options here...
> >
> > - 0 = Hello (Multicast to ALL PIM ROUTERS)
> > - 1 = Register (Unicast to RP)
> > - 2 = Register Stop (Unicast to source of Register packet)
> > - 3 = Join/Prune (Multicast to ALL PIM ROUTERS)
> > - 4 = Bootstrap (Multicast to ALL PIM ROUTERS)
> > - 5 = Assert (Multicast to ALL PIM ROUTERS)
> >
> > - Note we also send the version of the PIM too...
> >
> > 2. Wondering about the IP of the RP?
> >
> > 3. Wondering about the IP of Router B (the PIM neighbor who is in the
> path
> > or tree to the RP).
> >
> > What is the Destination IP of the PIM we sent out in item number 1?
> >
> > - 224.0.0.13
> >
> > What are we expecting in return?
> >
> > - The IP of the RP
> >
> > Where are we expecting to receive it from in general?
> >
> > - From a neighbor
> >
> > which neighbor in this little example?
> >
> > - Router B
> >
> > Why would we expect to receive the RP's IP from this neighbor?
> >
> > - Because it is the closest router that is also a shared PIM neighoor and
> > knows of the shared tree to the RP.
> >
> >
> > Now let's introduce Router C. Router C is on the same shared segment as
> > Router A and Router B. Router C also has an interface that is in the same
> > segment as Router A and Router B. Furthermore, that interface is also PIM
> > enabled.
> >
> > So...
> >
> > If the destination IP address of the Join is 224.0.0.13 and 224.0.0.13 is
> > "All PIM Routers" (In our case Router B and Router C)...
> >
> > Then the question becomes "How do we determine which router will act on
> > this Join and not say... both routers?"
> >
> > Hmmm...
> >
> > Give it a minute to sink in...
> >
> > Remember we know that the upstream neighbor is the target of the
> message...
> > right?
> >
> > Ok - Let me see if I can finish writing up this basic example and clear
> > some clouds up.
> >
> > The idea is to take the concept and expound on it.
> >
> > We watched Narbik do this from a CLI perspective quite wonderfully and
> > masterfully.
> >
> > I've been spending a little time trying to ensure I understand what is
> > actually happening first and foremost... then I'll take the example(s)
> and
> > break them down from a CLI perspective with various show or debug
> commands
> > when/if/as needed.
> >
> > The idea is to:
> >
> > 1. Understand the concept. In this case we need to fully understand that
> a
> > Multicast Router needs a few things to work:
> >
> > - Be enabled on the router (Hey -meet me half way - ip muticast-routing
> or
> > ip mulitcast-routing ditributed)
> > - Be enabled on the interface in the correct mode (Gotta have the correct
> > operational mode- Sparse, Sparse-Dense, or Dense)
> > - Have a neighor that is PIM enable (Neighbor Check)
> > - Have a route (usually via IGP for example) to the RP (RPF Check)
> > - Know where the source is located (IP Address)
> >
> > 2. Once we understand the concept and the components then we need to know
> > the basic configuration commands.
> >
> > 3. Then we need to know the basic verification exams.
> >
> > ---------------------------------------------------------
> > At this point, I'd say we are still at a CCNP level
> > ----------------------------------------------------------
> >
> > 4. Then we need to know those special commands use to help MCAST overcome
> > hurdles as they might be presented in the Lab.
> >
> > 5. We also need to ensure we understand all the show and debug output at
> an
> > expert's level.
> >
> > 6. Items 1-5 will allow us to correctly configure and troubleshoot IP
> > Multicast in the CCIE Lab both effeciently and effectively - resulting in
> > 100% of the Mlticast Points that may or may not be available in any given
> > lab.
> >
> >
> > Now let's introduce Router C. Router C is on the same shared segment as
> > Router A and Router B. Router C also has an interface that is in the same
> > segment as Router A and Router B. Furthermore, that interface is also PIM
> > enabled.
> >
> > So...
> >
> > If the destination IP address of the Join is 224.0.0.13 and 224.0.0.13 is
> > "All PIM Routers" (In our case Router B and Router C)...
> >
> > Then the question becomes "How do we determine which router will act on
> > this Join and not say... both routers?"
> >
> > Hmmm...
> >
> > Give it a minute to sink in...
> >
> > Remember we know that the upstream neighbor is the target of the
> message...
> > right?
> >
> > Let's see...
> >
> > Where was I...
> >
> > Oh yes, how does Router A know whether to use Router B or Router C as the
> > next hop upstream router if both are PIM enabled neighbors?
> >
> > Hmm...
> >
> > Well for this we need a little more information. Like the IP Address of
> > each. In this case let's say that Router A is 172.16.123.1, Router B is
> > 172.16.123.2, and router C is 172.16.123.3....
> >
> > Now which is selected?
> >
> > Think about it.
> >
> > Hmm....
> >
> > Ok - I'll be back later with the correct answer
> >
> >
> > In this case they are directly connected. So the IP Address would be the
> > tie breaker and the hisghest will be Router A's choice for the next hop.
> >
> > Router C is the winner.
> >
> >
> >
> >
> > On Sun, Aug 2, 2009 at 11:42 PM, sameer khan <skkingpk11253006_at_gmail.com
> >wrote:
> >
> >> Hi
> >> Confuse about the active source in multicasting
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards,
Joe Astorino - CCIE #24347 R&S
Technical Instructor - IPexpert, Inc.
Cell: +1.586.212.6107
Fax: +1.810.454.0130
Mailto:  jastorino_at_ipexpert.com
Blogs and organic groups at http://www.ccie.net