Explain Multicast Operation

0:00Well, we have three primary traffic types on our networks that we have to support. We have unicast traffic, which is naturally one to one. I send a unicast packet from one end of the network to the other, and it's from one sender to one receiver. And then broadcast packets. These get sent out to everyone on the network. If I've got five hosts and only two of these hosts need to receive it, well, guess what? Everyone is receiving this broadcast frame or a broadcast packet. And then lastly, we have multicast.

0:30And so multicast is trying to solve the problem of broadcast by saying, yeah, we've got all of these different hosts on the network, but maybe two of these hosts want to receive it. And these other two hosts, they have no idea it exists or they just don't want to receive that traffic. And so because of the way the network is designed, we're going to very efficiently get that multicast packet across the network and to those specific hosts without delivering it to the other hosts. Furthermore, as we scale this out to layer three domains, we know that multic ast is able to 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, let's say this is a router in this case. And then this router will replicate the packet as many times as needed. And so I save a lot of bandwidth by not having to send all of these other packets or copies of the packet along to this router, instead, it can create the copies of the packet after only receiving a single one. And the best part about multicast is this is a function of the network, not of the edge hosts.

1:41So the source multicast source just needs to send its packets, its multicast stream onto the network, and the network handles the rest. So it offloads a heavy amount of responsibility to the network, and it does so in a more efficient way. So multicast is usually win-win, everybody wins when we deploy multicast. Unfortunately for us, in a lot of cases, multicast is fairly or unfairly perceived as being extremely complex.

2:12And so we think that, well, we may be we're not going to deploy multicast. Sometimes it's a lot easier just to deploy a broadcast solution. When it comes to our data centers, especially our large scale data centers, we often have to deploy multicast. And so we need to make sure that we understand multicast. And of course, by the end of this, that we're able to troubleshoot multicast problems. Now multicast, the way this works is we have a source on the network. And 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 this architecture out, we're going to have a single source here. And this source is going to send its packets with a destination address that we call the group address. The group address takes the format of an IPv4 or IPv6 address. And when we're talking about an IPv4 address, these would be known as class D addresses. So class C takes us all the way up to 223 as an IP address.

3:18Well class D goes into the 224 range. And so anything starting with a 224 through 239 can be used as an IPv4 group address. The 239 addresses, so for example, let's say 239.1.1.1, to be a great example of a 239 address, these are known as, let me write down here. These are known as private addresses in the multicast space. I'm going to use quotes here because essentially what we're saying is anybody can use these addresses.

3:50We think about private IPv4 addresses like 10.1.1.1 as a private address. I might have this address in my network. You might have it in your network. And that's perfectly fine because our two networks aren't actually communicating directly using those addresses. So that'd be the IPv4 unicast version, a multicast version of that would be the 239 range. So I might have 239.1.1 in my network. And you can use it in your network as well. Pretty 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 using that 239 address range. Now from here, we've got the group address and we also have multicast receivers that are once again out on the network somewhere. So I'm going to draw these as end hosts or end clients. And so then of course we have the network in the middle. So the idea here is I could send one packet to this router and it'll send another packet to this router.

4:55And maybe we've even got two other routers in here at this point replication of the packet happens. So I send one copy to the router up top. I send another copy to the router on the bottom. And then they each send it to the appropriate station downstream. So again, these are the primary components of multicast and we've a lot of responsibility falls on the network in order to make all of this happen, which of course, when I say the responsibility is on the network, of course, I mean the responsibility is on us as the network admins.

5:26Now, there are three different types of multicast or at least three primary types that we're going to be talking about here. The first of which is known as any source multicast or ASM as the name implies, we don't care what the source is. We don't care what source we're using. So we don't care which source we use.

5:58This is sort of the traditional multicast architecture. If we think about multicast and we think about forming trees and rendezvous points and all of these things, I mean, we're forming trees either way, but especially if we think about dense mode and rendezvous points and such, we're usually talking about ASM. The idea here is I might have multiple servers out on the network and they're both sending the exact same stream into the network. So 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. So let's put it on a different subnet. We'll say 10.10.10.1. So two totally different data centers, they're both producing the exact same multicast stream when my user, my end multicast receiver wants to join this group with any source multicast we are saying, I don't care which one of these I get, I just want one of them. The assumption there is that this group address 239.1.1.1 in our case is the exact same stream and it doesn't matter which source I connect to.

7:12Furthermore, I don't have to know the source address. So that's one piece of information we don't have to feed the station, we just need the station to know what the group address is. Now a question that certainly when I was first learning multicast, I really scratched my head and I know a lot of students do when we're first talking about multicast is, okay, but how does the receiver know what that group address is? How does it know to go out and get 239.1.1.1? Well that conversation happens at layer eight, I mean beyond the networking layers.

7:47So there's lots of ways to do it, it depends on the application. Naturally, we might have a centralized application that sends that information out to the stations and so it's something we might have to configure on the application and then it propagates information out. Maybe we have to manually configure it into an application, maybe it's a tele conferencing application or something along those lines, but the point is that the network is not responsible for handing that information out. For now, we'll use the quotes again, somehow, somehow we need the station, the receiver, to already have that information.

8:23Unfortunately, whatever application we're deploying, usually they have a way to propagate that information out to the different receivers. Now the second type of multicast is known as source specific. Multicast. Source specific multicast is sort of the opposite of any source. Multicast, because we do care about the source and furthermore, we need to know the source.

9:00Now there's good news and bad news with source specific multicast. Usually source specific multicast is simpler to deploy, which is really good for us in the networking world. We're so focused on rendezvous points and all of these things and with source specific multicast, we don't need some of that architecture. It makes things a lot simpler. The downside is that now we do have to know the source, as I just wrote out there, which is extra information that we have to propagate and depending on our network and the scale of our network, maybe the source address could change depending on failover and new applications and all of these things.

9:39And furthermore, we do need to make sure that we're deploying the version three of IgMP. We'll talk about that in a little bit, but we do need to make sure that the architecture supports it. This requires a little bit more modern technology. Now again, in the 2020s decade that we're in, we should definitely have source specific multicast capabilities on all of the networking hardware that we deploy. It's been around for a long time at this point, but we do still need to make sure that it's configured. So 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 what we should be deploying. Now the other type of multicast that we're going to want to deploy, or at least be aware that we can deploy is known as bidirectional multicast. And this is usually just referred to as BIDIR. So pronounce that however you want. But ultimately, the concept here is that we are going to have a many to many application type.

10:46So we said earlier that multicast up here is one to many. And that's a little bit of at least it's flossing over some of the details to put it that way. So one to many is typically what we want to deploy. And so that's why we are usually using any source multicast or source specific multicast. But what happens if we have a many to many application? For example, we mentioned video conferencing.

11:18Video conferencing would be an application that we have a lot of different hosts. So we talk about maybe hosts all around the network. Let's say we've got the six different users and they're all engaging in a video conference. Well, this user needs its information to be sent to all five of the other hosts . Well guess what? Everybody else needs this as well. We're going to end up creating a full mesh here. That's close enough probably. But we're going to create a full mesh of communications and yeah, we could use the unit cast for that.

11:52But multicast makes it far more efficient. The problem is we can't use any source multicast and we can't use source specific multicast because this only supports one direction. It supports one source to many hosts. So if we want to have many to many, then we're going to need to use bidirection al multicast or bidirectional pin as it's usually referred to as. Now the other thing to consider is in the data center space, we might well see this used for our VXLAN and leaf spine fabrics.

12:27We don't always need to deploy bidirectional pin, but at the same time, oft entimes we will see this deployed into those architectures. So this is absolutely on the table for a troubleshooting multicast conversation inside of the data center space. Now one last thing to note in all of this and it has to do with our focus here, especially as it relates to the DCIT, is that multicast has two separate operation types. We have layer two multicast and we have layer three.

12:57Layer two multicast uses the internet group message protocol or IgMP. This is what I mentioned earlier where IgMP version two is typically what gets default deployed, but we're going to need IgMP version three explicitly deployed if we want to support source specific multicast. The idea here is that we've got an edge router. We have a network here, this layer two domain, and we've got all of the different hosts that are trying to request to join specific groups.

13:29We also have sources that are trying to push multicast streams out onto the network. We've got a join groups, we have to leave groups, we have to make sure from a layer two perspective that maybe these three hosts all get the stream, but the other two hosts don't. There's a lot that happens in the layer two world and this is not the focus of this conversation or the exam for that matter. In fact, on the exam, we're really focused on troubleshooting PIM specifically. PIM, which is protocol independent multicast, is the layer three element.

14:04The layer three element happens between the layer two domains because naturally we do eventually get to another layer two domain where we've got other hosts or potentially sources. And so layer two handle the IgMP handles these layer two domains and PIM is really focused here in the middle. PIM is going to help us get our multicast traffic all the way across the network, not only as efficiently as possible, but also in a loop-free fashion. So from here, we're going to again focus on PIM and just trust that layer two multicast is 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 data center spaces.

0:00Well, as we just mentioned, PIM is responsible for getting us through layer 3 devices and getting a packet from when it first arrives on one of these routers via the source, all the way through the network properly replicated by the way, as it goes, so one packet here, splitting into two packets here, and then getting it to the destination routers , which will deliver it onto the network where the receivers are. Now we call it protocol independent multicast for a reason.

0:34Protocol independence means that we do not care what the underlying unicast routing protocol is. So this is a very big part of the multicast architecture is we ended up as an industry building this, we call PIM, such that we can use EIGRP, we could use OSPF, we could use RIP if we really wanted to, we could use BGP, and we could use static routes, it doesn't care. What 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 that it is stable. We don't want routes flapping around because that will cause disruption to our multicast environment. Now PIM actually behaves a little bit like an IGP. And the reason for that is IGP behavior. And when I say IGP, I'm talking about these routing protocols, the EIGRP, OSPF and what not, but it's going to form neighbor relationships and it's going to do so via multicast, which might seem a little chicken and egg from the perspective that I need PIM to use multicast and yet here I am using multicast to form PIM relationships.

1:55But this is local multicast. So these are specifically going out and just trying to get out to the other routers on a layer 2 segment without bothering all the other hosts. It's why we use multicast between EIGRP and OSPF neighbors, for example. So we're doing the same concept here, but we are just forming relationships up here on the network between our layer 3 devices. So we're going to exchange messages. We could do a show IP PIM neighbor, for example, and that's going to show that we've got neighbors on the other side of whatever connection we have.

2:31Now these multicast addresses, we should be a little familiar with, it's going to be using 224.0.0.13 for PIM in the IPv4 space. And once again, we're going to find that the IPv6 multicast address is very similar. Just keep in mind that IPv6 uses hexadecimal. We might expect it to end in 13 and it does end in 13 except 13 looks like a capital D because that would be 13 in hexadecimal. So we are exchanging these multicast messages, we're forming PIM neighbors and ideally at the end of just setting up PIM, we've got all of our routers communicating with one another in this space.

3:13Now the goal of PIM is, well, there's actually a lot of goals, but we are going to start to install multicast routes, which starts to feel a little bit more like that routing protocol behavior again, except multicast routes, they have some similarities to unicast routes, but they're also extremely different. Okay, these multicast routes are not, well, here I'll say it like this, they are not exchanged when we talk about EIGRP and OSPF, we talk about exchanging routes, making sure that we 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. Instead what we're doing is we are forming trees. The goal of PIM is to form these multicast trees. And just like, if we think about the word tree, we also see that in the word spanning tree, for example, just like with spanning tree, the goal of a tree ultimately is to create a loop free topology for traffic to flow down.

4:22So I can allow traffic to flow, say traffic flows here, which means that regardless of where the multicast source is, regardless of where the receivers are, we can expect that our multicast traffic is going to get from end to end. Now in our, in our topology in the top left, we didn't make a looped environment. But let's say that we have a connection here between these two routers on the right, we form a PIM adjacency there. So now we've got all of these different PIM relationships.

4:56Well, a tree, a multicast tree might look something like this. We've got the source, we've got the receivers. But the last thing we would want, for example, is to have multicast looking like this, because now I send a packet, it gets sent down like this, they get sent back and forth. And now all of a sudden we've got a routing loop. So instead PIM wants to form a loop free topology. And so it might look like this, it might look like this, but either way, this concept should feel very similar to spanning tree in that we're trying to create that loop free topology that simply allows traffic to flow from one end of the network to the other, such that again, our source can transmit the multicast traffic to the receivers .

5:43Now multicast routes come in two different forms. Let me change colors here. So we have what we call the star, G multicast entry. And then we also have the S, G multicast entry. So let's talk about both of these. So a star, G, I equate this to sort of a template. It's showing us what we want to do when multicast traffic arrives, but importantly, no multicast source has been discovered.

6:17So we have no source yet at this point, but we do have receivers. Keep in mind in all of this that a source might be the first one to show up or receivers might be the first one to show up. We might have receivers that are waiting for multicast traffic to show up, or we might have a source that's trying to send multicast traffic onto the network and there's no one there to receive it yet. And so we've got to be thinking from an architecture perspective that any of these things can happen, right?

6:49We could have the receivers there with no source, we could have the source there with no receivers, or we could have ultimately sources and receivers at the same time. And so we have to think about things from that perspective. So what happens, again, if I have receivers on the network, but I don't yet have a source, well, we'd install the star, comma, G route. And what the star, comma, G route gives us is it gives us a list of outgoing interfaces.

7:20Now we have a fancy acronym for this, we call it the outgoing interface list or the OIL, or we could call it the oil, I suppose usually the OIL is what we refer to it as. Sounds a little weird to talk about oil on our routers, but I guess maybe some of them could use a tune up at this point. Let's be real. But either way, we'll just call that the OIL. And it tells a router where to direct the multicast traffic. So if I've got a router like this, and I've got four different interfaces, the question is 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 going to have those in the list. So let's say this is gig zero zero, and this is gig zero one, and then we'll just say gig zero two and gig zero three are up here. So the OIL in this case will have gig zero zero and gig zero one listed. And so the reason why I call it a template, and I'm just going to put quotes in there, because that's more of a Jeff Kish thing than anything you'll necessarily read. But the reason we call it a template, or I call it a template, is because when multicast traffic inevitably arrives, so now all of a sudden we have real traffic show up , we need to 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 send it out gig zero one. So now we need to talk about this s, g group with or s, g route entry, which I ran out of space there. So I'm erasing it, though we can talk about it down here. So now we have the s, g. The s, g says that we now have a source. That's what the s stands for. The source is a specific source.

9:10This is an IP address. It might be something like 10 dot one dot one dot one. If our source, let's say up here on the diagram is 10 dot one dot one dot one like that. Well, now we've got this entry. And you'll notice that when we said star up here, now we kind of know what the star meant. Star or asterisk is very commonly used as a wild card. And so we're truly saying any source. It doesn't matter what source comes in or what, yeah, what source generates this traffic. I have a group address like 239 dot one dot one dot one.

9:43And I have receivers that want this group address. And so I don't care which source generates it. All I know is when traffic is received, I'm going to send it out these specific interfaces. Well now that I have a source, I can build an actual s, g entry that is based on this template. And so I can say that my s, g, so 10 dot one dot one dot one comma, 239 dot one dot one dot one, this entry, again, s for the source, g for the group, has an incoming interface.

10:21Let's say it comes in here this time. So incoming interface is gig zero two. And the outgoing interface list, I simply pull down from the template. So gig zero zero and gig zero one. The template help the template rather tells me that OIL populates it for me because I know that there are receivers out those interfaces. Now multi cast, very importantly, will never bring traffic in on one interface and send it out the same interface that could create loops.

10:55So let's say that we actually got this in on gig zero one. Were there receivers downstream there? Yeah. But we have to assume that they have already gotten the stream or that they're going to get the stream another way. So in that case, if we said that the incoming interfaces gig zero one, I would still use this as a template, but I wouldn't include gig zero one in the outgoing interface list. So that's again, where the template concept comes from, which says, okay, we know all the interfaces that we want to send this multi cast stream out, but we can't send it out the interface that we received it on.

11:31And so it's very important that we identify what that incoming interface is. Now one of the reasons why it's so important that we recognize that has to do with the fact that again, we are trying to generate loop free trees or loop free top ologies. Now the way that PIM performs this loop free concept is it relies on the fact that unicast, a unicast environment is loop free.

12:06This is part of the protocol independent multicast. We are relying on this point here that we have layer three convergence. So if the unicast environment is loop free, we can base our multicast environment on the unicast environment. And so we're going to use a check that is pretty popular in the networking world. We call it the reverse forwarding, a reverse path, our PF check, a reverse path forwarding check. And I'll just put that in here, our PF check.

12:43The RPF check is going to take a look at that incoming interface. So right here, we said that we have an incoming interface for this scoma g entry of gig zero one. And so, and specifically by the way, we said that we're using this IP address of 10 dot one that one dot one. So we are going to perform this check. How do we perform this check? Well, we are going to check the unicast, unicast routing table to find out what the outgoing interface would be.

13:17And, finally, if I were to want to send a packet to 10 dot one dot one, where would I send the packet? So I'm going to check that and find out, okay, would I send it to gig zero or send it out gig zero one? If I got a packet in to the router destined for 10 dot one dot one dot one, would I then send it out gig zero one? That's the reverse path forwarding check. I 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 would go out that interface. And if so, then that is good. But there will be times where we say, no, actually, I would have sent that packet out gig zero three. And so if this isn't the case, then we will reject this multicast traffic. We will drop it. We will not install the s, comma G route because ultimately that means that we have a loop in the network.

14:22If we look at the top left, essentially what that saying is, let's say that our traffic is actually coming down, trying to find a color that will work here. There we go. So we send multicast traffic out. It goes to these two different routers. And then this router on top wants to send it down to this other router. But we know that that would create a loop. And so ideally what's happening here is I get it from 10. So 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. And so at that point, basically I have two different options to choose from. I have these two different packets showing up. I can't accept both of them. I only need one. So I'm going to check that routing table. If the routing table says that this is the path towards 10 dot 1 dot 1 dot 1, I 'm going to reject the packet that's getting sent down from the other router. And that again creates that loop free topology. So 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. And if there's ever a problem with RPF checks dropping our packets, then there might be a problem with our unicast topology because again, we are making some assumptions, especially around 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 lab and take a look at how this looks at the CLI. And so what we want to do here is we want to take this topology and this top ology is available here in this skill. We can download it. It is completely configured for OSPF and multicast. Basically all the work is done for us. All we need to do is to run some show commands and make sure we understand how multicast routes are being installed given the scenario. The scenario is that we have a multicast source over here on the left that's router 11.

0:30These are iOS routers that are serving as our source and destination or source and receiver. And so our multicast source is sending traffic out onto the network like this. And the goal is for the receiver to receive it over here. Now looking at the topology, we would probably make a valid assumption that the multicast traffic would take this link here in the middle. But of course, we want to verify that we know and understand what's happening in this topology as we deploy it. Now the multicast receiver is requesting group 239.

1:01We write that down 239.1.1. And so if that source exists out on the network, then our job as network devices is to for that traffic along. Router 11 is our source, but it's not actually creating that traffic. So let's go ahead and have router 11 create that traffic and the way we do that is simply by pinging that address. 239.1.1.1. And we'll say repeat 100,000, anything like that. We just want to be generating traffic.

1:32Now this ping command might work and might not. And I know it looks like this ping is failing because we're not getting any response back. But pinging a multicast address sometimes works again, sometimes doesn't, especially when we're using iOS routers for the source and destination. If the receiver is running the command that we want it to run, so run int gig one, this command right here is what's telling this router to join that group, but it doesn't always respond to multicast.

2:03And so that's perfectly fine. So again, we're just trying to generate traffic. Now we want to go check the network to find out if it's sending that traffic along accordingly. Now we'll go to Nexus 9K1 up here. This should be the receiving layer three device. There's a VLAN interface on here. We're on VLAN 11. And the first thing we should probably do is do a show IP PIM neighbor to make sure we have PIM adjacencies. So again, PIM is like a routing protocol. And we would expect it to have neighbors. And so show IP PIM neighbor is going to tell us that on Nexus 1 here, we have a neighbor out ethernet one slash one, which is 9K2.

2:40And it's the dot two at the end there of the neighbor ID. Anything dot two is Nexus two, dot three is Nexus three. So Nexus three here is out ethernet one slash two. And so the PIM adjacencies look good. We could go make sure that the other two are adjacent to each other, but yeah, we're good there. So now let's take a look at the multicast routes. But I want to do, you know, look at the unicast routes. I do show IP route. Multicast is show IPM route. So show IPM route is telling us here. Actually it's kind of interesting.

3:11So we've got the source comma group. So this is an scoma g entry. The source is router 11 as we see on the diagram, 10 dot 11 dot 11 dot 11. And the group is the right group 239 dot 1 dot 1. We also see an incoming interface. But at the time at the moment here, the outgoing interface list is empty. So let's go and take a look at Nexus three and find out what's going on here. Alright, so Nexus three has actually lost the connection here.

3:45The idea has lost awareness that router 22 is requesting to join this group. Now this is another facet of this command. It's just kind of a sometimes with turning it into a receiver. We have to shut and no shut it in order to prompt it to ask again. So I'm going to do that. I'm going to shut this interface down. Do a no shut. And ideally it'll send that I GMP join request out once again, which should tell the 9K 3 that somebody downstream wants it.

4:19So there we go. So that actually opened the floodgates. So what happened here was that router 22 is going to send an I GMP message out into the world not knowing who's going to receive it, but somebody's going to receive it in this case. It would be the upstream layer through device Nexus 9K 3. And at that point it knows that somebody downstream wants this multicast stream . So its job is to install a star, which basically says I don't know what sources are out there, but I do know the group and I know somebody wants this out my VLAN 22 interface .

4:58So if we look at the star, right here, again, don't care about the source. I just know if I get a multicast packet destined for 239.1.1 then I need to send it out this list of interfaces. In this case we just have a single interface VLAN 22. This being a layer three interface, any other layer three interface can show up here, whether it's sub interfaces or physical layer three interfaces, but in this case it is an SVI. So we installed the star, G. Now through the magic of this PIM sparse mode environment, and we'll be talking about that magic coming up, thanks to a rendezvous point up here, we 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. Now the source we know is 10.11.11.11, which is VLAN 11, which lives on Nexus 9 K1. How do I know where to go with that? Well I check my routing table. I see that 10.11.11/24 exists out ethernet one/one out towards my Nexus 9K1, which is so that's where we send the PIM JOIN request. And so we end up joining up there and we do see that we have an S-comaG entry now, because we 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 every three minutes, let's see here. Now these entries haven't timed out because they're less than three minutes, but ultimately 9K1, we're getting, yeah, no. 9K1 here has timed out, so we didn't actually see the, oh no, I'm sorry it is, yeah we don't see the star comma G, so that one timed out which is interesting. But we do see this S-comaG entry that's not star comma G because it's upstream, so I miss spoke on that one.

6:57But either way, we've got the group here 239.1.1.1 and the source. And now earlier, remember we saw that was coming in on VLAN 11, which is true, we didn't know where to send it. Now we know where to send it. We're sending it out ethernet one/two, and so this traffic is actually flowing down to router 22. The problem here is just that again, this ping doesn't usually work when we're using iOS devices as our multicast receiver. But we do see where there are star comma Gs and we see where there are S-coma G s, there's no star comma G here because all, again, at this point we know about the source , we're specifically joining that source.

7:39We don't, 9K1 doesn't have any direct, directly attached receivers. So it is just responding to 9K3 saying, "Oh, you want this source and group? You want this S-coma G? All right, we'll add you into the OIL and so we will send the multicast traffic out that interface." So that is, again, it is an opportunity for us to download this, configure it in CML, or apply the scripts into your own environment, and do some testing as far as how multicast works 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. Make sure that we understand the nature of multicast traffic. At this point, it's still a very high level conversation and we'll be diving more into the details here coming up in this course. We start with the question about the type of communication enabled by multicast . So the key here is it's going to enable one to many as the primary goal of multicast. And so that's certainly one of the answers. I want this multicast source to send traffic into the network and every packet I send will get 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. That's the big difference in multicast and broadcast because broadcast will go to everyone. So it's a one to all type of situation with broadcast and we don't necessarily want to send traffic to everyone. Now the many to many is the other answer choice here and that's because we have that concept of bidirectional PIM that we talked about, which if we think about video conf erencing, we might have all of those units or those devices that are out on the network that need to communicate with each other.

1:08So we kind of create this full mesh of communications among all of these devices. And in the end, we do want all of them to be able to talk to all of them. So that would be many to many. The next question is talking about PIM, what do we mean when we say PIM is protocol independent? Well multicast is going to require a converged unicast architecture. I need to be able to ping across my environment as a test to make sure that anyone can reach anyone.

1:40If we don't have converged layer three unicast, we cannot deploy multicast on top of it. But that's all PIM cares about. It doesn't care how we get there. As we said, we could use EIGRP or OSPF or even static routes, and BGP RIP if we really wanted to, as long as we have converged layer three PIM doesn't care what protocol we use. There are other options that tied to specific routing protocols that the industry didn't lock in on. And that's really nice because now we don't have to worry about what we used to build our unicast when we're talking about deploying multicast potentially for the first time.

2:17Now what type of multicast route is used when a source is known? Remember, we've got the two different types of routes. We have the star, and we have S, that star, that asterisk is usually used when we mean it's a wildcard. We don't know what goes there. Maybe anything could go there. And so this is what we called the template type of route. And it's what we use when we have no source. We don't know what source is out there. And ultimately, once we do learn what source is out there, we're not going to get rid of the template route because we want to keep that to potentially build other routes for that group for different sources.

2:58But at the same time, it's not tied to a specific source. And so we are going to use the S, G when the source is known. We're going to build that S, G for the source. And we're going to use that to propagate the traffic from the source all the way to the receiver. Now, lastly, how many entries are expected in an incoming and outgoing interface section? So remember, when we have a multicast route or an M route, we have the incoming interface and we have the outgoing interface list.

3:31Those names pretty much answer this question for us. We have a single incoming interface. And then the outgoing interface list is a list of interfaces. So this can truly be many, which is exactly what we have up here with this diagram. We see that we have a single incoming interface. I should maybe point to the router itself. We have a packet coming in on one interface and it's going out a bunch of interfaces. Now this might change a little bit when we talk about bidirectional PIM, but as far as any source multicast and source specific multicast, which is most of our multicast deployments, that 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 conversation. We're not here to dive all the way deep into multicast, but we do need to at least understand it at a high level and then understand how to troubleshoot it, keeping in mind that we always have the ability to dive deeper into multicast outside of this specific course. As we've said with some of the other technologies, it's expected that we have some of this knowledge coming in to this conversation. So if this was a little bit too much, then be sure to fire up either the DC core course or 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 conversation, we understand what the routes are doing, we understand what PIM is, and coming up here, we're going to dive deeper into the concept of what PIM ultimately is driving towards and creating these trees and how exactly that gets done. I hope this has been informative for you, and I'd like to thank you for viewing .