Re: hi

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
Received on Mon Aug 03 2009 - 00:07:35 ART