Explain Multicast Operation

0:00Well, we have three primary traffic types on our networks that we have to

0:05support.

0:05We have unicast traffic, which is naturally one to one.

0:08I send a unicast packet from one end of the network to the other, and it's from

0:12one sender

0:13to one receiver.

0:14And then broadcast packets.

0:17These get sent out to everyone on the network.

0:19If I've got five hosts and only two of these hosts need to receive it, well,

0:23guess what?

0:24Everyone is receiving this broadcast frame or a broadcast packet.

0:29And then lastly, we have multicast.

0:30And so multicast is trying to solve the problem of broadcast by saying, yeah,

0:35we've got all

0:36of these different hosts on the network, but maybe two of these hosts want to

0:39receive it.

0:40And these other two hosts, they have no idea it exists or they just don't want

0:44to receive

0:45that traffic.

0:46And so because of the way the network is designed, we're going to very

0:50efficiently get that multicast

0:52packet across the network and to those specific hosts without delivering it to

0:57the other hosts.

0:59Furthermore, as we scale this out to layer three domains, we know that multic

1:04ast is able

1:04to be very efficient with how we replicate traffic.

1:08I only need to send, for example, one frame to, let's say the edge node here,

1:13let's say

1:13this is a router in this case.

1:17And then this router will replicate the packet as many times as needed.

1:21And so I save a lot of bandwidth by not having to send all of these other

1:24packets or copies

1:25of the packet along to this router, instead, it can create the copies of the

1:30packet after

1:31only receiving a single one.

1:33And the best part about multicast is this is a function of the network, not of

1:39the edge

1:40hosts.

1:41So the source multicast source just needs to send its packets, its multicast

1:48stream onto

1:49the network, and the network handles the rest.

1:53So it offloads a heavy amount of responsibility to the network, and it does so

1:57in a more efficient

1:58way.

1:59So multicast is usually win-win, everybody wins when we deploy multicast.

2:05Unfortunately for us, in a lot of cases, multicast is fairly or unfairly

2:09perceived as

2:10being extremely complex.

2:12And so we think that, well, we may be we're not going to deploy multicast.

2:15Sometimes it's a lot easier just to deploy a broadcast solution.

2:18When it comes to our data centers, especially our large scale data centers, we

2:23often have

2:24to deploy multicast.

2:26And so we need to make sure that we understand multicast.

2:29And of course, by the end of this, that we're able to troubleshoot multicast

2:33problems.

2:34Now multicast, the way this works is we have a source on the network.

2:42And usually we have one source speaking at a time.

2:44Now naturally this scales up to many sources, but just for the sake of building

2:49this architecture

2:50out, we're going to have a single source here.

2:52And this source is going to send its packets with a destination address that we

2:58call the

2:59group address.

3:02The group address takes the format of an IPv4 or IPv6 address.

3:07And when we're talking about an IPv4 address, these would be known as class D

3:12addresses.

3:13So class C takes us all the way up to 223 as an IP address.

3:18Well class D goes into the 224 range.

3:21And so anything starting with a 224 through 239 can be used as an IPv4 group

3:28address.

3:29The 239 addresses, so for example, let's say 239.1.1.1, to be a great example

3:35of a 239

3:37address, these are known as, let me write down here.

3:41These are known as private addresses in the multicast space.

3:45I'm going to use quotes here because essentially what we're saying is anybody

3:48can use these

3:49addresses.

3:50We think about private IPv4 addresses like 10.1.1.1 as a private address.

3:56I might have this address in my network.

3:58You might have it in your network.

4:00And that's perfectly fine because our two networks aren't actually

4:03communicating directly

4:04using those addresses.

4:06So that'd be the IPv4 unicast version, a multicast version of that would be the

4:11239 range.

4:12So I might have 239.1.1 in my network.

4:17And you can use it in your network as well.

4:20Pretty much everything else up to 239 is reserved in various ways.

4:24And so if we're deploying our own multicast application, we should really be

4:27using that

4:28239 address range.

4:31Now from here, we've got the group address and we also have multicast receivers

4:37that

4:37are once again out on the network somewhere.

4:41So I'm going to draw these as end hosts or end clients.

4:45And so then of course we have the network in the middle.

4:47So the idea here is I could send one packet to this router and it'll send

4:52another packet

4:53to this router.

4:55And maybe we've even got two other routers in here at this point replication of

4:59the packet

5:00happens.

5:01So I send one copy to the router up top.

5:04I send another copy to the router on the bottom.

5:06And then they each send it to the appropriate station downstream.

5:10So again, these are the primary components of multicast and we've a lot of

5:15responsibility

5:16falls on the network in order to make all of this happen, which of course, when

5:19I say

5:20the responsibility is on the network, of course, I mean the responsibility is

5:24on us as the network

5:25admins.

5:26Now, there are three different types of multicast or at least three primary

5:31types that we're

5:32going to be talking about here.

5:34The first of which is known as any source multicast or ASM as the name implies,

5:44we don't

5:45care what the source is.

5:48We don't care what source we're using.

5:50So we don't care which source we use.

5:58This is sort of the traditional multicast architecture.

6:02If we think about multicast and we think about forming trees and rendezvous

6:06points and all

6:07of these things, I mean, we're forming trees either way, but especially if we

6:10think about

6:10dense mode and rendezvous points and such, we're usually talking about ASM.

6:15The idea here is I might have multiple servers out on the network and they're

6:22both sending

6:23the exact same stream into the network.

6:26So maybe we're sending to 239.1.1.1 and these servers are 10.1.1.1 and 10.1.

6:34Actually, maybe these are on a totally different data center.

6:38So let's put it on a different subnet.

6:39We'll say 10.10.10.1.

6:41So two totally different data centers, they're both producing the exact same

6:45multicast stream

6:47when my user, my end multicast receiver wants to join this group with any

6:54source multicast

6:56we are saying, I don't care which one of these I get, I just want one of them.

7:02The assumption there is that this group address 239.1.1.1 in our case is the

7:08exact same stream

7:09and it doesn't matter which source I connect to.

7:12Furthermore, I don't have to know the source address.

7:18So that's one piece of information we don't have to feed the station, we just

7:21need the

7:22station to know what the group address is.

7:26Now a question that certainly when I was first learning multicast, I really

7:29scratched my head

7:30and I know a lot of students do when we're first talking about multicast is,

7:34okay, but

7:34how does the receiver know what that group address is?

7:37How does it know to go out and get 239.1.1.1?

7:41Well that conversation happens at layer eight, I mean beyond the networking

7:46layers.

7:47So there's lots of ways to do it, it depends on the application.

7:50Naturally, we might have a centralized application that sends that information

7:55out to the stations

7:56and so it's something we might have to configure on the application and then it

7:59propagates

8:00information out.

8:01Maybe we have to manually configure it into an application, maybe it's a tele

8:04conferencing

8:05application or something along those lines, but the point is that the network

8:10is not responsible

8:11for handing that information out.

8:13For now, we'll use the quotes again, somehow, somehow we need the station, the

8:20receiver,

8:21to already have that information.

8:23Unfortunately, whatever application we're deploying, usually they have a way to

8:28propagate that

8:28information out to the different receivers.

8:31Now the second type of multicast is known as source specific.

8:38Multicast.

8:42Source specific multicast is sort of the opposite of any source.

8:46Multicast, because we do care about the source and furthermore, we need to know

8:58the source.

9:00Now there's good news and bad news with source specific multicast.

9:03Usually source specific multicast is simpler to deploy, which is really good

9:09for us in

9:09the networking world.

9:11We're so focused on rendezvous points and all of these things and with source

9:14specific

9:14multicast, we don't need some of that architecture.

9:17It makes things a lot simpler.

9:18The downside is that now we do have to know the source, as I just wrote out

9:24there, which

9:26is extra information that we have to propagate and depending on our network and

9:30the scale

9:31of our network, maybe the source address could change depending on failover and

9:36new applications

9:37and all of these things.

9:39And furthermore, we do need to make sure that we're deploying the version three

9:44of

9:44IgMP.

9:45We'll talk about that in a little bit, but we do need to make sure that the

9:47architecture

9:48supports it.

9:49This requires a little bit more modern technology.

9:52Now again, in the 2020s decade that we're in, we should definitely have source

9:58specific

9:59multicast capabilities on all of the networking hardware that we deploy.

10:03It's been around for a long time at this point, but we do still need to make

10:06sure that it's

10:06configured.

10:07So generally speaking, I will say that we like source specific multicast.

10:12If we can deploy source specific multicast in a lot of cases, that's exactly

10:16what we

10:16should be deploying.

10:18Now the other type of multicast that we're going to want to deploy, or at least

10:23be aware

10:24that we can deploy is known as bidirectional multicast.

10:32And this is usually just referred to as BIDIR.

10:35So pronounce that however you want.

10:37But ultimately, the concept here is that we are going to have a many to many

10:43application

10:45type.

10:46So we said earlier that multicast up here is one to many.

10:53And that's a little bit of at least it's flossing over some of the details to

10:59put it

11:00that way.

11:01So one to many is typically what we want to deploy.

11:04And so that's why we are usually using any source multicast or source specific

11:09multicast.

11:10But what happens if we have a many to many application?

11:14For example, we mentioned video conferencing.

11:18Video conferencing would be an application that we have a lot of different

11:24hosts.

11:25So we talk about maybe hosts all around the network.

11:27Let's say we've got the six different users and they're all engaging in a video

11:31conference.

11:32Well, this user needs its information to be sent to all five of the other hosts

11:38.

11:38Well guess what?

11:40Everybody else needs this as well.

11:41We're going to end up creating a full mesh here.

11:46That's close enough probably.

11:47But we're going to create a full mesh of communications and yeah, we could use

11:51the unit

11:51cast for that.

11:52But multicast makes it far more efficient.

11:55The problem is we can't use any source multicast and we can't use source

11:59specific multicast

12:01because this only supports one direction.

12:04It supports one source to many hosts.

12:08So if we want to have many to many, then we're going to need to use bidirection

12:12al multicast

12:13or bidirectional pin as it's usually referred to as.

12:17Now the other thing to consider is in the data center space, we might well see

12:21this used

12:22for our VXLAN and leaf spine fabrics.

12:27We don't always need to deploy bidirectional pin, but at the same time, oft

12:31entimes we will

12:32see this deployed into those architectures.

12:35So this is absolutely on the table for a troubleshooting multicast conversation

12:40inside

12:40of the data center space.

12:43Now one last thing to note in all of this and it has to do with our focus here,

12:46especially

12:47as it relates to the DCIT, is that multicast has two separate operation types.

12:54We have layer two multicast and we have layer three.

12:57Layer two multicast uses the internet group message protocol or IgMP.

13:04This is what I mentioned earlier where IgMP version two is typically what gets

13:08default

13:08deployed, but we're going to need IgMP version three explicitly deployed if we

13:13want to support

13:14source specific multicast.

13:16The idea here is that we've got an edge router.

13:19We have a network here, this layer two domain, and we've got all of the

13:24different hosts that

13:25are trying to request to join specific groups.

13:29We also have sources that are trying to push multicast streams out onto the

13:34network.

13:35We've got a join groups, we have to leave groups, we have to make sure from a

13:39layer

13:39two perspective that maybe these three hosts all get the stream, but the other

13:44two hosts

13:44don't.

13:45There's a lot that happens in the layer two world and this is not the focus of

13:50this conversation

13:51or the exam for that matter.

13:53In fact, on the exam, we're really focused on troubleshooting PIM specifically.

13:59PIM, which is protocol independent multicast, is the layer three element.

14:04The layer three element happens between the layer two domains because naturally

14:09we do

14:09eventually get to another layer two domain where we've got other hosts or

14:12potentially

14:13sources.

14:15And so layer two handle the IgMP handles these layer two domains and PIM is

14:20really focused

14:22here in the middle.

14:25PIM is going to help us get our multicast traffic all the way across the

14:28network, not

14:29only as efficiently as possible, but also in a loop-free fashion.

14:33So from here, we're going to again focus on PIM and just trust that layer two

14:38multicast

14:38is happening for the most part will address it as needed.

14:42But again, the goal here is to understand and troubleshoot PIM inside of our

14:47data center

14:48spaces.

0:00Well, as we just mentioned, PIM is responsible for getting us through layer 3

0:05devices and

0:06getting a packet from when it first arrives on one of these routers via the

0:12source, all

0:12the way through the network properly replicated by the way, as it goes, so one

0:17packet here,

0:18splitting into two packets here, and then getting it to the destination routers

0:22, which

0:22will deliver it onto the network where the receivers are.

0:29Now we call it protocol independent multicast for a reason.

0:34Protocol independence means that we do not care what the underlying unicast

0:39routing protocol

0:40is.

0:41So this is a very big part of the multicast architecture is we ended up as an

0:47industry

0:48building this, we call PIM, such that we can use EIGRP, we could use OSPF, we

0:56could use

0:57RIP if we really wanted to, we could use BGP, and we could use static routes,

1:01it doesn't

1:01care.

1:02What it really cares about is that we have layer 3 convergence.

1:07We need to make sure that we can access all of the subnets in the network and

1:12that it

1:12is stable.

1:14We don't want routes flapping around because that will cause disruption to our

1:18multicast

1:19environment.

1:20Now PIM actually behaves a little bit like an IGP.

1:27And the reason for that is IGP behavior.

1:30And when I say IGP, I'm talking about these routing protocols, the EIGRP, OSPF

1:35and what

1:36not, but it's going to form neighbor relationships and it's going to do so via

1:43multicast, which

1:45might seem a little chicken and egg from the perspective that I need PIM to use

1:50multicast

1:50and yet here I am using multicast to form PIM relationships.

1:55But this is local multicast.

1:58So these are specifically going out and just trying to get out to the other

2:03routers on

2:04a layer 2 segment without bothering all the other hosts.

2:06It's why we use multicast between EIGRP and OSPF neighbors, for example.

2:11So we're doing the same concept here, but we are just forming relationships up

2:15here on

2:16the network between our layer 3 devices.

2:19So we're going to exchange messages.

2:21We could do a show IP PIM neighbor, for example, and that's going to show that

2:26we've got neighbors

2:28on the other side of whatever connection we have.

2:31Now these multicast addresses, we should be a little familiar with, it's going

2:34to be using

2:35224.0.0.13 for PIM in the IPv4 space.

2:41And once again, we're going to find that the IPv6 multicast address is very

2:48similar.

2:49Just keep in mind that IPv6 uses hexadecimal.

2:51We might expect it to end in 13 and it does end in 13 except 13 looks like a

2:56capital D

2:57because that would be 13 in hexadecimal.

3:00So we are exchanging these multicast messages, we're forming PIM neighbors and

3:04ideally at

3:05the end of just setting up PIM, we've got all of our routers communicating with

3:09one another

3:10in this space.

3:13Now the goal of PIM is, well, there's actually a lot of goals, but we are going

3:18to start

3:19to install multicast routes, which starts to feel a little bit more like that

3:23routing

3:23protocol behavior again, except multicast routes, they have some similarities

3:28to unicast routes,

3:29but they're also extremely different.

3:32Okay, these multicast routes are not, well, here I'll say it like this, they

3:39are not exchanged

3:40when we talk about EIGRP and OSPF, we talk about exchanging routes, making sure

3:46that

3:47we tell each other about the routes that are attached and all of these things.

3:51And that's not exactly what's happening with multicast routes.

3:56Instead what we're doing is we are forming trees.

4:01The goal of PIM is to form these multicast trees.

4:06And just like, if we think about the word tree, we also see that in the word

4:10spanning tree,

4:11for example, just like with spanning tree, the goal of a tree ultimately is to

4:16create

4:16a loop free topology for traffic to flow down.

4:22So I can allow traffic to flow, say traffic flows here, which means that

4:32regardless of

4:32where the multicast source is, regardless of where the receivers are, we can

4:36expect that

4:36our multicast traffic is going to get from end to end.

4:40Now in our, in our topology in the top left, we didn't make a looped

4:44environment.

4:46But let's say that we have a connection here between these two routers on the

4:49right, we

4:49form a PIM adjacency there.

4:52So now we've got all of these different PIM relationships.

4:56Well, a tree, a multicast tree might look something like this.

5:00We've got the source, we've got the receivers.

5:02But the last thing we would want, for example, is to have multicast looking

5:08like this, because

5:10now I send a packet, it gets sent down like this, they get sent back and forth.

5:15And now all of a sudden we've got a routing loop.

5:18So instead PIM wants to form a loop free topology.

5:21And so it might look like this, it might look like this, but either way, this

5:25concept

5:26should feel very similar to spanning tree in that we're trying to create that

5:30loop free

5:30topology that simply allows traffic to flow from one end of the network to the

5:36other,

5:36such that again, our source can transmit the multicast traffic to the receivers

5:43.

5:43Now multicast routes come in two different forms.

5:46Let me change colors here.

5:49So we have what we call the star, G multicast entry.

5:54And then we also have the S, G multicast entry.

5:59So let's talk about both of these.

6:01So a star, G, I equate this to sort of a template.

6:08It's showing us what we want to do when multicast traffic arrives, but

6:13importantly, no multicast

6:15source has been discovered.

6:17So we have no source yet at this point, but we do have receivers.

6:25Keep in mind in all of this that a source might be the first one to show up or

6:29receivers

6:29might be the first one to show up.

6:31We might have receivers that are waiting for multicast traffic to show up, or

6:35we might

6:36have a source that's trying to send multicast traffic onto the network and

6:39there's no one

6:40there to receive it yet.

6:41And so we've got to be thinking from an architecture perspective that any of

6:47these things can

6:48happen, right?

6:49We could have the receivers there with no source, we could have the source

6:51there with

6:51no receivers, or we could have ultimately sources and receivers at the same

6:56time.

6:56And so we have to think about things from that perspective.

6:59So what happens, again, if I have receivers on the network, but I don't yet

7:05have a source,

7:06well, we'd install the star, comma, G route.

7:10And what the star, comma, G route gives us is it gives us a list of outgoing

7:18interfaces.

7:20Now we have a fancy acronym for this, we call it the outgoing interface list or

7:24the OIL,

7:26or we could call it the oil, I suppose usually the OIL is what we refer to it

7:29as.

7:29Sounds a little weird to talk about oil on our routers, but I guess maybe some

7:34of them

7:34could use a tune up at this point.

7:36Let's be real.

7:37But either way, we'll just call that the OIL.

7:41And it tells a router where to direct the multicast traffic.

7:45So if I've got a router like this, and I've got four different interfaces, the

7:51question

7:51is where are their receivers as far as PIM is concerned.

7:55So if there are receivers out this interface and this interface, well, I'm

7:59going to have

8:00those in the list.

8:02So let's say this is gig zero zero, and this is gig zero one, and then we'll

8:06just say

8:06gig zero two and gig zero three are up here.

8:09So the OIL in this case will have gig zero zero and gig zero one listed.

8:16And so the reason why I call it a template, and I'm just going to put quotes in

8:20there,

8:20because that's more of a Jeff Kish thing than anything you'll necessarily read.

8:24But the reason we call it a template, or I call it a template, is because when

8:28multicast

8:29traffic inevitably arrives, so now all of a sudden we have real traffic show up

8:34, we need

8:35to know what to do with this traffic.

8:37And the OIL tells us exactly what to do with it, send it out gig zero zero and

8:41send it

8:41out gig zero one.

8:43So now we need to talk about this s, g group with or s, g route entry, which I

8:49ran out

8:50of space there.

8:51So I'm erasing it, though we can talk about it down here.

8:56So now we have the s, g.

8:59The s, g says that we now have a source.

9:04That's what the s stands for.

9:06The source is a specific source.

9:10This is an IP address.

9:11It might be something like 10 dot one dot one dot one.

9:14If our source, let's say up here on the diagram is 10 dot one dot one dot one

9:18like that.

9:19Well, now we've got this entry.

9:22And you'll notice that when we said star up here, now we kind of know what the

9:25star

9:26meant.

9:27Star or asterisk is very commonly used as a wild card.

9:31And so we're truly saying any source.

9:33It doesn't matter what source comes in or what, yeah, what source generates

9:38this traffic.

9:39I have a group address like 239 dot one dot one dot one.

9:43And I have receivers that want this group address.

9:47And so I don't care which source generates it.

9:49All I know is when traffic is received, I'm going to send it out these specific

9:54interfaces.

9:55Well now that I have a source, I can build an actual s, g entry that is based

10:02on this

10:03template.

10:04And so I can say that my s, g, so 10 dot one dot one dot one comma, 239 dot one

10:11dot one

10:12dot one, this entry, again, s for the source, g for the group, has an incoming

10:19interface.

10:21Let's say it comes in here this time.

10:24So incoming interface is gig zero two.

10:27And the outgoing interface list, I simply pull down from the template.

10:31So gig zero zero and gig zero one.

10:38The template help the template rather tells me that OIL populates it for me

10:42because I

10:43know that there are receivers out those interfaces.

10:47Now multi cast, very importantly, will never bring traffic in on one interface

10:52and send

10:52it out the same interface that could create loops.

10:55So let's say that we actually got this in on gig zero one.

11:00Were there receivers downstream there?

11:02Yeah.

11:03But we have to assume that they have already gotten the stream or that they're

11:06going to

11:06get the stream another way.

11:08So in that case, if we said that the incoming interfaces gig zero one, I would

11:12still use

11:13this as a template, but I wouldn't include gig zero one in the outgoing

11:17interface list.

11:18So that's again, where the template concept comes from, which says, okay, we

11:22know all

11:22the interfaces that we want to send this multi cast stream out, but we can't

11:27send it

11:28out the interface that we received it on.

11:31And so it's very important that we identify what that incoming interface is.

11:36Now one of the reasons why it's so important that we recognize that has to do

11:41with the

11:41fact that again, we are trying to generate loop free trees or loop free top

11:52ologies.

11:54Now the way that PIM performs this loop free concept is it relies on the fact

12:00that unicast,

12:01a unicast environment is loop free.

12:06This is part of the protocol independent multicast.

12:09We are relying on this point here that we have layer three convergence.

12:14So if the unicast environment is loop free, we can base our multicast

12:18environment on the

12:19unicast environment.

12:21And so we're going to use a check that is pretty popular in the networking

12:25world.

12:26We call it the reverse forwarding, a reverse path, our PF check, a reverse path

12:32forwarding

12:34check.

12:35And I'll just put that in here, our PF check.

12:43The RPF check is going to take a look at that incoming interface.

12:49So right here, we said that we have an incoming interface for this scoma g

12:55entry of gig zero

12:57one.

12:58And so, and specifically by the way, we said that we're using this IP address

13:02of 10 dot

13:02one that one dot one.

13:04So we are going to perform this check.

13:06How do we perform this check?

13:07Well, we are going to check the unicast, unicast routing table to find out what

13:15the

13:15outgoing interface would be.

13:17And, finally, if I were to want to send a packet to 10 dot one dot one, where

13:22would

13:22I send the packet?

13:24So I'm going to check that and find out, okay, would I send it to gig zero or

13:30send it out

13:32gig zero one?

13:33If I got a packet in to the router destined for 10 dot one dot one dot one,

13:39would I then

13:40send it out gig zero one?

13:43That's the reverse path forwarding check.

13:45I received multicast from this source address on this interface.

13:51I want to make sure that if I were to send traffic back to that source, that it

13:54would

13:55go out that interface.

13:57And if so, then that is good.

14:01But there will be times where we say, no, actually, I would have sent that

14:04packet out

14:05gig zero three.

14:07And so if this isn't the case, then we will reject this multicast traffic.

14:14We will drop it.

14:15We will not install the s, comma G route because ultimately that means that we

14:20have

14:20a loop in the network.

14:22If we look at the top left, essentially what that saying is, let's say that our

14:28traffic

14:28is actually coming down, trying to find a color that will work here.

14:33There we go.

14:34So we send multicast traffic out.

14:36It goes to these two different routers.

14:38And then this router on top wants to send it down to this other router.

14:43But we know that that would create a loop.

14:46And so ideally what's happening here is I get it from 10.

14:51So the source is 10 dot 1 dot 1 dot 1.

14:55But this router knows that the routing table says to send it this way.

15:00And so at that point, basically I have two different options to choose from.

15:04I have these two different packets showing up.

15:06I can't accept both of them.

15:08I only need one.

15:09So I'm going to check that routing table.

15:11If the routing table says that this is the path towards 10 dot 1 dot 1 dot 1, I

15:15'm going

15:15to reject the packet that's getting sent down from the other router.

15:21And that again creates that loop free topology.

15:24So the RPF check is a big part of our multicast world.

15:28We need to understand that that is going to cause us to drop packets.

15:32And if there's ever a problem with RPF checks dropping our packets, then there

15:36might be

15:37a problem with our unicast topology because again, we are making some

15:42assumptions, especially

15:43around having a converged and stable layer three environment.

0:00Well, after so much time at the chalkboard, I think it's time to jump into the

0:04lab and

0:05take a look at how this looks at the CLI.

0:08And so what we want to do here is we want to take this topology and this top

0:11ology is

0:11available here in this skill.

0:12We can download it.

0:14It is completely configured for OSPF and multicast.

0:18Basically all the work is done for us.

0:19All we need to do is to run some show commands and make sure we understand how

0:23multicast routes

0:23are being installed given the scenario.

0:26The scenario is that we have a multicast source over here on the left that's

0:29router 11.

0:30These are iOS routers that are serving as our source and destination or source

0:34and receiver.

0:36And so our multicast source is sending traffic out onto the network like this.

0:40And the goal is for the receiver to receive it over here.

0:43Now looking at the topology, we would probably make a valid assumption that the

0:47multicast

0:48traffic would take this link here in the middle.

0:51But of course, we want to verify that we know and understand what's happening

0:54in this

0:55topology as we deploy it.

0:57Now the multicast receiver is requesting group 239.

1:01We write that down 239.1.1.

1:07And so if that source exists out on the network, then our job as network

1:11devices is to for

1:12that traffic along.

1:14Router 11 is our source, but it's not actually creating that traffic.

1:18So let's go ahead and have router 11 create that traffic and the way we do that

1:21is simply

1:22by pinging that address.

1:24239.1.1.1.

1:26And we'll say repeat 100,000, anything like that.

1:30We just want to be generating traffic.

1:32Now this ping command might work and might not.

1:35And I know it looks like this ping is failing because we're not getting any

1:38response back.

1:40But pinging a multicast address sometimes works again, sometimes doesn't,

1:44especially

1:44when we're using iOS routers for the source and destination.

1:48If the receiver is running the command that we want it to run, so run int gig

1:56one, this

1:57command right here is what's telling this router to join that group, but it

2:01doesn't always

2:01respond to multicast.

2:03And so that's perfectly fine.

2:04So again, we're just trying to generate traffic.

2:06Now we want to go check the network to find out if it's sending that traffic

2:11along accordingly.

2:13Now we'll go to Nexus 9K1 up here.

2:14This should be the receiving layer three device.

2:16There's a VLAN interface on here.

2:18We're on VLAN 11.

2:20And the first thing we should probably do is do a show IP PIM neighbor to make

2:24sure we

2:24have PIM adjacencies.

2:26So again, PIM is like a routing protocol.

2:29And we would expect it to have neighbors.

2:31And so show IP PIM neighbor is going to tell us that on Nexus 1 here, we have a

2:36neighbor

2:37out ethernet one slash one, which is 9K2.

2:40And it's the dot two at the end there of the neighbor ID.

2:43Anything dot two is Nexus two, dot three is Nexus three.

2:46So Nexus three here is out ethernet one slash two.

2:48And so the PIM adjacencies look good.

2:50We could go make sure that the other two are adjacent to each other, but yeah,

2:55we're

2:55good there.

2:56So now let's take a look at the multicast routes.

2:59But I want to do, you know, look at the unicast routes.

3:02I do show IP route.

3:04Multicast is show IPM route.

3:07So show IPM route is telling us here.

3:10Actually it's kind of interesting.

3:11So we've got the source comma group.

3:14So this is an scoma g entry.

3:17The source is router 11 as we see on the diagram, 10 dot 11 dot 11 dot 11.

3:22And the group is the right group 239 dot 1 dot 1.

3:26We also see an incoming interface.

3:28But at the time at the moment here, the outgoing interface list is empty.

3:34So let's go and take a look at Nexus three and find out what's going on here.

3:40Alright, so Nexus three has actually lost the connection here.

3:45The idea has lost awareness that router 22 is requesting to join this group.

3:53Now this is another facet of this command.

3:56It's just kind of a sometimes with turning it into a receiver.

4:00We have to shut and no shut it in order to prompt it to ask again.

4:05So I'm going to do that.

4:06I'm going to shut this interface down.

4:07Do a no shut.

4:09And ideally it'll send that I GMP join request out once again, which should

4:15tell the 9K 3

4:17that somebody downstream wants it.

4:19So there we go.

4:20So that actually opened the floodgates.

4:22So what happened here was that router 22 is going to send an I GMP message out

4:30into the

4:30world not knowing who's going to receive it, but somebody's going to receive it

4:34in this

4:35case.

4:36It would be the upstream layer through device Nexus 9K 3.

4:39And at that point it knows that somebody downstream wants this multicast stream

4:44.

4:44So its job is to install a star, which basically says I don't know what sources

4:50are out there,

4:52but I do know the group and I know somebody wants this out my VLAN 22 interface

4:58.

4:58So if we look at the star, right here, again, don't care about the source.

5:03I just know if I get a multicast packet destined for 239.1.1 then I need to

5:10send it out this

5:11list of interfaces.

5:13In this case we just have a single interface VLAN 22.

5:16This being a layer three interface, any other layer three interface can show up

5:21here, whether

5:21it's sub interfaces or physical layer three interfaces, but in this case it is

5:27an SVI.

5:27So we installed the star, G. Now through the magic of this PIM sparse mode

5:32environment,

5:33and we'll be talking about that magic coming up, thanks to a rendezvous point

5:36up here,

5:37we are able to figure out that there is a source out on the network.

5:41And so we end up building out towards the source.

5:44Now the source we know is 10.11.11.11, which is VLAN 11, which lives on Nexus 9

5:51K1.

5:52How do I know where to go with that?

5:53Well I check my routing table.

5:56I see that 10.11.11/24 exists out ethernet one/one out towards my Nexus 9K1,

6:04which is

6:04so that's where we send the PIM JOIN request.

6:09And so we end up joining up there and we do see that we have an S-comaG entry

6:15now, because

6:15we discovered the source once the multicast packet arrived.

6:19Going back to 9K1, which actually I bet we lost it again, times out I think

6:24every three

6:24minutes, let's see here.

6:27Now these entries haven't timed out because they're less than three minutes,

6:32but ultimately

6:339K1, we're getting, yeah, no.

6:369K1 here has timed out, so we didn't actually see the, oh no, I'm sorry it is,

6:43yeah we don't

6:43see the star comma G, so that one timed out which is interesting.

6:47But we do see this S-comaG entry that's not star comma G because it's upstream,

6:55so I miss

6:56spoke on that one.

6:57But either way, we've got the group here 239.1.1.1 and the source.

7:03And now earlier, remember we saw that was coming in on VLAN 11, which is true,

7:07we didn't

7:08know where to send it.

7:09Now we know where to send it.

7:10We're sending it out ethernet one/two, and so this traffic is actually flowing

7:15down to

7:16router 22.

7:17The problem here is just that again, this ping doesn't usually work when we're

7:21using

7:22iOS devices as our multicast receiver.

7:26But we do see where there are star comma Gs and we see where there are S-coma G

7:30s, there's

7:31no star comma G here because all, again, at this point we know about the source

7:36, we're

7:37specifically joining that source.

7:39We don't, 9K1 doesn't have any direct, directly attached receivers.

7:45So it is just responding to 9K3 saying, "Oh, you want this source and group?

7:51You want this S-coma G?

7:52All right, we'll add you into the OIL and so we will send the multicast traffic

7:58out that

7:58interface."

8:00So that is, again, it is an opportunity for us to download this, configure it

8:04in CML,

8:05or apply the scripts into your own environment, and do some testing as far as

8:09how multicast

8:10works as well as when the Star Comagee and S Comagee entries get installed.

0:00All right, let's chat a little bit about some of these questions.

0:04Make sure that we understand the nature of multicast traffic.

0:07At this point, it's still a very high level conversation and we'll be diving

0:10more into

0:10the details here coming up in this course.

0:13We start with the question about the type of communication enabled by multicast

0:17.

0:17So the key here is it's going to enable one to many as the primary goal of

0:23multicast.

0:24And so that's certainly one of the answers.

0:26I want this multicast source to send traffic into the network and every packet

0:31I send will

0:31get replicated as needed so that the hosts that want to see it can get it.

0:37But the hosts that don't want to see that traffic won't actually see it.

0:41That's the big difference in multicast and broadcast because broadcast will go

0:44to everyone.

0:45So it's a one to all type of situation with broadcast and we don't necessarily

0:50want to

0:50send traffic to everyone.

0:53Now the many to many is the other answer choice here and that's because we have

0:56that concept

0:57of bidirectional PIM that we talked about, which if we think about video conf

1:01erencing,

1:02we might have all of those units or those devices that are out on the network

1:06that need to communicate

1:07with each other.

1:08So we kind of create this full mesh of communications among all of these

1:13devices.

1:13And in the end, we do want all of them to be able to talk to all of them.

1:17So that would be many to many.

1:20The next question is talking about PIM, what do we mean when we say PIM is

1:24protocol independent?

1:26Well multicast is going to require a converged unicast architecture.

1:33I need to be able to ping across my environment as a test to make sure that

1:38anyone can reach

1:39anyone.

1:40If we don't have converged layer three unicast, we cannot deploy multicast on

1:44top of it.

1:45But that's all PIM cares about.

1:47It doesn't care how we get there.

1:49As we said, we could use EIGRP or OSPF or even static routes, and BGP RIP if we

1:56really

1:57wanted to, as long as we have converged layer three PIM doesn't care what

2:02protocol we use.

2:03There are other options that tied to specific routing protocols that the

2:07industry didn't

2:08lock in on.

2:09And that's really nice because now we don't have to worry about what we used to

2:12build

2:13our unicast when we're talking about deploying multicast potentially for the

2:16first time.

2:17Now what type of multicast route is used when a source is known?

2:20Remember, we've got the two different types of routes.

2:24We have the star, and we have S, that star, that asterisk is usually used when

2:32we mean

2:33it's a wildcard.

2:34We don't know what goes there.

2:35Maybe anything could go there.

2:37And so this is what we called the template type of route.

2:41And it's what we use when we have no source.

2:45We don't know what source is out there.

2:47And ultimately, once we do learn what source is out there, we're not going to

2:51get rid

2:51of the template route because we want to keep that to potentially build other

2:55routes for

2:56that group for different sources.

2:58But at the same time, it's not tied to a specific source.

3:02And so we are going to use the S, G when the source is known.

3:08We're going to build that S, G for the source.

3:11And we're going to use that to propagate the traffic from the source all the

3:16way to the

3:17receiver.

3:18Now, lastly, how many entries are expected in an incoming and outgoing

3:21interface section?

3:22So remember, when we have a multicast route or an M route, we have the incoming

3:27interface

3:28and we have the outgoing interface list.

3:31Those names pretty much answer this question for us.

3:33We have a single incoming interface.

3:37And then the outgoing interface list is a list of interfaces.

3:42So this can truly be many, which is exactly what we have up here with this

3:46diagram.

3:47We see that we have a single incoming interface.

3:50I should maybe point to the router itself.

3:53We have a packet coming in on one interface and it's going out a bunch of

3:57interfaces.

3:58Now this might change a little bit when we talk about bidirectional PIM, but as

4:02far

4:02as any source multicast and source specific multicast, which is most of our

4:06multicast deployments,

4:08that is how M routes are going to come together.

4:11So if you need to kind of go back and review any of this, multicast is a long

4:16conversation.

4:17We're not here to dive all the way deep into multicast, but we do need to at

4:22least understand

4:23it at a high level and then understand how to troubleshoot it, keeping in mind

4:26that we

4:27always have the ability to dive deeper into multicast outside of this specific

4:33course.

4:34As we've said with some of the other technologies, it's expected that we have

4:37some of this knowledge

4:38coming in to this conversation.

4:40So if this was a little bit too much, then be sure to fire up either the DC

4:45core course

4:46or the encore course to kind of look more at multicast and get that down.

4:52But as far as a refresher is concerned, hopefully coming out of this

4:56conversation, we understand

4:57what the routes are doing, we understand what PIM is, and coming up here, we're

5:00going to

5:01dive deeper into the concept of what PIM ultimately is driving towards and

5:05creating

5:05these trees and how exactly that gets done.

5:08I hope this has been informative for you, and I'd like to thank you for viewing

5:10.