Cisco Multicast Routing for CCNA, CCNP, and CCIE Candidates

hey everybody it's Kevin Wallace CC CAA and Cisco press author and in this video I'm going to simplify multi casting for you how it works and how to configure it stay tuned what I want to do with you in this video is take the topic of multicast and break it down in a simplified way still covering a lot of technical detail we're going to be diving deep into multicast but I want to present it in such a way that you're going to get a ton of multicast understanding in this one video let's get started by taking a look at the benefit of multicast what is multicast what are the other options why do we want to do multi casting well consider this let's say that we've got a video server and I've got three pcs and I use that term pcs generically you might say hey that looks like a Mac that's not a PC we've got these three different devices on the network and two of these pcs they want to receive video and the third one PC number three does not want to receive video let's think about different ways of getting the video to the PCs that do want to receive the video we could use unicast with unicast our video server would be sending out a packet to each of those pcs for every video packet each PC gets sent its own copy we send a packet to PC one we send a packet to PC two and then we go over and over with that again well as you can imagine that's not going to scale terribly well it might be fine with two pcs but what if I had 50 pcs that wanted to receive this video stream can you imagine the video server having to send out 50 copies of every video packet that's not terribly efficient it's going to cause a lot of processor overhead on the video server and it's going to cause a lot of bandwidth usage on that link to which the video server is connected let's take a look at another option another option is broadcast here the video server saves tons of Aine with it saves tons of processing because it only sends each video packet one time that one packet goes to all of the pcs on the local subnet well that's good in that the two pcs that wanted to get the got it the video server only had to send each packet one time but as the downside PC number three it received a video packet and it did not want to receive a video packet its network interface card had to take time out of its day to look at that packet and say that's not for me I don't want that and discard it so what's a better option well you could probably guess based on the title of this video it's multicast with multicast we get the benefit of the video server just sending each pack at once and only the intended recipients get the packet how can we do that well what we're going to do is have the PCs that want to receive the video we're going to have them join a multicast group and a multicast group in the IP version 4 world is going to be a Class D address we'll talk about IP version 6 little bit later as well but in the IP version 4 world we've got a Class D address twice T that's where the first octet is in the range of to 24 through 239 well here we've got a class T group of 239 1.1.1 and these two pcs have joined that group or so now the video server is going to send out the packet one time and it only goes to the intended recipients PC 3 does not have to see it that's one of the big benefits of multicast and I mentioned that multicast in the IP version 4 world is going to use a Class D address stuck a bit more about that here is the Class D address range to 2400 all the way through to 39 to 5 5 to 5 5 to 5 5 but there are some reserved addresses in that range I want you to know about first of all we've got some link local addresses and a link local address and you see the address range here on-screen that address is only usable on the local network segment only usable on one link and some of our routing protocols use addresses in this range for example OSPF it uses 220 for 0.05 and to 2400 6 rip version 2 it uses these two 2409 erp it uses to 2400 TN another class of address that we have is 224 0.10 all the way through 238 geordie of our class d address space these are referred to as globally scoped addresses they're not limited to a single link as an example but within this globally scoped address range we still have some subsets of ranges that are reserved let's take a look at another one of those we next have the source-specific multicast addresses these Class D addresses have a 232 in the first octet now what is source-specific multicast e well later in this video we're going to see that a client that wants to belong to a multicast group can send up a message we're going to learn that it's the IGMP message that it sends up saying hey I want to join this multicast group and with a specific version of IGMP IGMP version 3 that device is able to say not only do I want to belong to this group and receive traffic's into this group I only want to receive traffic from specific sources we can say I want to join a specific multicast group but I want to receive traffic from this specific server or these specific servers in the next class of address our first octet is a 233 these are referred to as glop addresses that's a fun word to say you might think that glop is some sort of an acronym but really it's not that's just the name of these addresses and glop addresses can be globally unique multicast addresses that are based on an autonomous system number like a BGP autonomous system number that a company might have for example let's say that we had autonomous system number 65,000 just as an example in that case our glop address that will be globally unique would be 233 250 3.2 32 zero all the way through 233 253 232 255 you see the second and third octet were determined by our autonomous system number here's the way that breaks down in my example a 65,000 in decimal equals FD e 8 in hexadecimal now FD if we look at just those two hexadecimal digits those two hexadecimal digits in isolation equal to 53 that's what we're going to use for our second octet and ei if we look at those two an isolation that equals to 32 in decimal that's the third octet of our glop address and we also have a limited scope address this is why I oftentimes use in my labs and in my demonstrations because this is a limited scope address think of this much like a private IP address like you use the 10 network inside of your network maybe you do NAT to get out to the rest of the internet but inside of your network you might use 10 dot addressing or 170 2016 addressing or 192 dot 168 addressing it's much like that for multicast well that's a look at IP version for multicast addressing let's now consider IP version 6 multicast addressing IP version 6 doesn't have the concept of address classes there is no class de IP version 6 address however it is very easy to recognize an IP version 6 multicast address because it begins with FF and if our first two hexadecimal digits are both F's that means the first 8 binary bits in this 128 bit address they're going to be all ones let's take a look at the example on-screen let's say that pc1 & pc2 they want to receive this video stream from our video server they might join a multicast address of FF 0 4 : : 10 and our video server could send traffic that just goes to those 2 B C's pc 3 does not have to see it however beyond those first 8 bits we also have a flags field and a scope field let's consider the flags field first of all there are 4 bits here they're called the 0 RP and T bits the 0 bit is call that because it's reserved it is going to be set to a zero but the our bit could be set to a 1 and if it is set to a 1 that means the P and the T bits they also have to be set to a 1 if they are that would indicate that there is a rendezvous point address embedded in the multicast address and we're going to talk a lot about a rendezvous point a little bit later in this video but just to give you an idea right now a rendezvous point is a router that's sort of a relay station if I want to receive multicast traffic destined for a multicast group what I could do is tell the rendezvous point that I want to receive that traffic and it could send it to me more on that later but the RP and T bits they're going to indicate whether or not a rendezvous point address is embedded in the multicast address what about the scope field what's going on there well we've got several different possible values for our scope and I'll put them on screen here just as a reference for you nothing to really memorize but you can see that several of these are unassigned not all of these scope values have a meaning currently and some of the scope values would have a particular meaning such as a scope of a - that would be a link-local address we talked about that with IP version 4 multicast addressing think of a link local address as an address that is only relevant on a network segment it's not going to go between subnets we give you a couple of examples let's say that we have an IP address and IP version 6 address of FF 0 - colon colon 1 well that's a well-known IP version 6 multicast address that references all nodes in this link local scope the FF tells us hey this is a multicast address the 0 - is the scope it tells us that the scope is link local it's only valid on this network segment on this link and there is an assigned a value of 1 at the very end of this address to say that this represents all nodes in this link local scope another well known address is FF 0 - colon colon - this is all routers in this link local scope and now that we've talked about addressing and how it differs between IP version 4 and IP version 6 let's take a step back - IP version 4 in fact when we do some of our demonstrations later I'm primarily going to focus on IP version 4 some of the commands are pretty much identical with IP version 6 instead of saying IP we would say ipv6 but I'm going to do the demonstrations in IP version 4 and if we're talking about IP version 4 we know that we've got a 32-bit multicast address but if I'm sending a packet on an Ethernet network isn't enough for me to have this layer 3 address this multicast IP address no we've also got to have a layer 2 address don't we that layer 2 address is a MAC address and interestingly the multicast MAC address is automatically constructed from our IP version 4 multicast address let's go through an example let me show you how to do this conversion let's say we've got an IP version 4 a multicast address of 224 110 10 and we want to calculate the corresponding MAC address step 1 is to take the last three octets and convert those into binary that's what I've done here this is the binary representation of the last 3 octets and if the leftmost bit is not already set to 0 we should to a zero in this case it is so we have the same binary string we had back in step one now we want to convert each nibble as it's called into a hex value a nibble is a 4-bit value notice how I've put a dot after every four binary values the first nibble would be all zeros the next nibble is zero zero zero one if we convert that to hex that's a 1 well here I've taken all of those nibbles and converted them into hex values now that we've got this hex value we're going to prepend that hex value with zero one zero zero five e that's going to give us our final multicast MAC address of zero one zero zero five e zero one zero A zero A that's the multicast MAC address that corresponds to do 24 110 10 let's do one other example I want to point out something that's very interesting that you should keep in mind this time our IP version 4 multicast address is 2 24.1 29 1010 almost the same address except in the second octet we've got a 129 instead of 1 and we want to calculate the corresponding MAC address ok step one was to convert the last three octet Stuben Airy let's do that and we said in step two if the leftmost bit was not already a zero and it's not in this case we should make it a zero ok since it's not a zero the leftmost bit is a one we're going to convert it to a zero that gives us this binary string and does that look familiar it's exactly what we had in our previous exercise which means if we convert each of those nibbles into hex we're going to get the same hex strain if we prepend 0 1 0 0 5 e you guessed it we come up with the same multicast MAC address for a different multicast IP version 4 address that is an issue that we need to keep in mind as we are assigning a multicast MAC addresses on a network it is possible as we've just demonstrated to have overlapping multicast MAC addresses multicast MAC addresses that correspond to different IP version 4 addresses and now that we understand a bit more about what multicast is why is it valuable we understand a bit about the addressing for IP version 4 and IP version 6 let's see how it actually works on the network let's say that I've got a call love pcs that want to receive multicast traffic and they're going to be talking to their next hop router to say hey would you please send me this multicast traffic for this particular multicast group and the way the PC requests that multicast traffic is using a protocol called IGMP which stands for the internet group management protocol a lot of people think the M stands for multicast but actually it stands for management the internet group management protocol and we've got different versions of IGMP here on screen the rightmost PC it's running IGMP version one and the one of the left is running IGMP version two and the router is capable of doing IGMP version two well here's the difference between those two my IGMP version 1 receiver is going to send a packet up to the router saying hey I want to join to 39.1 dot 1.1 and at that point that router is going to know to send traffic destined for that group out of the interface off of which that receiver is connected if that router is not yet receiving traffic for that group then it needs to graft itself on to the multicast distribution tree it needs to talk to another router of the network saying hey can you start sending me traffic for this group I've got a guy over here that needs it and with IGMP version 1 there's a timer that's running on that router a 60-second timer and after 60 seconds that router is going to ask for the receiver hey do you still want to belong to 2:39 dot 1.1.1 because maybe that receiver no longer is interested maybe it powered off we're going to request an update every 60 seconds there's not a proactive way with IGMP version 1 for the receiver to say all right I'm out of here you can stop sending me traffic but that's the benefit we do get with IGMP version to hear the IGMP version 2 receiver it's going to send up an IGMP message to our router saying yes I also want to join group a 2:39 dot one dot one dot one and if no other device is connected off of that router interface our members of that multicast group the router can say I'm gonna start sending that traffic for that group out of this interface but now let's say that I am peepers onto receiver it's done it augur wants to receive this maybe it's a video stream it can proactively tell the router ok I'm done you can stop sending me traffic I want to leave group 239 dot one dot one dot one that was not possible with igmp version one only IGMP version2 could do that now you might be looking at this topology and thinking okay what is this 1995 is this a bus topology is this thick net is this thin net now I wanted to show you in theory what's going on with IGMP but in reality these pcs they're going to be connected into an Ethernet switch well here's the question if I've got an Ethernet switch connected into the router and connected into my receivers when it receives traffic for 239 1.1.1 how does it know out of which interface it should forward that traffic well what it can do is run something called igmp snooping we can do that on our Cisco Catalyst switches and it's going to eavesdrop in on those IGMP messages and it's going to see that a receiver wanted to belong to a particular group and it's going to memorize that information and when it sees that traffic coming back in destined for that group it's going to know that the receiver that wanted to receive that it's off of port maybe gigabit 1/0 so I'm going to Ford that traffic out of gigabit 1/0 but I'm not going to forward it out my other ports so the switch running igmp snooping it's constraining how far this multicast traffic gets now here we've demonstrated IGMP version 1 in version two there is an IGMP version 3 let me show you a different topology to illustrate the benefit of this with IGMP version 3 by the way in the real world you'll probably see IGMP version 2 most widely deployed today but I want you to know what IGMP version 3 is capable of here the PC is going to send up an IGMP version 3 message to the router and not only is it saying I want to receive traffic destined for the group of 239 1.1.1 it can say but I only want that traffic if it came from a specific source you see here we've got a couple of video servers maybe sending different video streams to the very same Class D address but they've got different IP addresses the different video servers so our IGMP receiver could say when it sends its message up to the router we could say I want to join group 239 dot one dot one dot one and include a source of 10.3 dot one dot one I want to receive traffic in other words just from video server number two that's not something we could do with IGMP versions one or two and one of the interesting characteristics of multicast is the way that initially multicast traffic might flood throughout the network going out of all router interfaces that are configured for multicast we're going to talk a little bit later in this video about exactly how that happens and how we can prevent that from happening but initially this multicast sender might be sending traffic to the receiver and it goes into r1 and r1 says well I've got a couple of exit interfaces they're both enabled for multicast and it sends the traffic out of both of its interfaces going to r2 and r3 which each send a packet to r4 that means the receiver it's getting a couple of packets it's getting a duplicate copy of the packet now what's going to prevent that from happening is something called RPF reverse path forwarding we don't want to receive duplicate copies so here's what r4 is going to do r4 is going to say all right I'm getting in some traffic and it's coming from 10.1.1.1 and I'm receiving this traffic coming in to gigabit 0/0 and in two gigabit 0/1 here's the question I want to ask if I were to send traffic back to 10.1.1.1 according to my unicast IP routing table which egress interface would I use we check our IP routing table and we see that to get to Network 10.11 interface would be gigabit zero size zero' well based on that router r4 says okay if I receive traffic from this multicast sender I'm only going to accept it if it came in to interface gigabit 0/0 if the traffic comes in gigabit 0/1 I'm going to drop it we're going to discard that packet that's reverse path forwarding and the benefit of that is the receiver is not receiving duplicate copies of a packet and the next huge concept we have to wrap our brains around as we're talking about multicast is the concept of a distribution tree when a multicast sender is sending out multicast packets those packets are going to travel over branches of a tree if you will and there's a couple of different types of trees we can have there's a source distribution tree and a shared at distribution tree and based on these trees we have a couple of different versions of something called Pam a P I M that's protocol independent multicast protocol independent means that it does not matter what our underlying IP routing protocol is this pin can ride on top of that it doesn't matter if we're using a rip or OSPF or a GRP we're independent of that unicast IP routing protocol think of pim as a multicast IP writing protocol and with a source distribution tree this cinder in the upper left-hand corner of your screen comes up on the network and it's going to be sending to a destination Class D address of 225 dot 1.2.3 and with a source distribution tree if we're running a PIM dense mode here's what happens router r1 is going to get that packet and it's going to flood it out all of its other interfaces r2 and r3 get it they flooded out of their interfaces did you see what happened there are three flooded the packet up to r2 r2 flooded the packet to r3 which then flooded the packet after the receiver the receiver got two copies of the same packet let's watch that again here's what happens with a source distribution tree we go into r1 it sends it out of its egress interfaces into r3 and r2 they send it to one another the receiver it got two copies of that packet well here's what's going to happen with PIM dense mode r2 is going to look around and say I don't have any interfaces that have received any sort of a join request I don't have any clients that have sent me an IgM P message saying that they want to belong to this multicast distribution tree I really don't think I need that to receive this multicast traffic and r3 that received a multicast packet from r2 it's going to say you do not need to send me anymore multicast traffic I'm already getting a copy of that from r1 that's my optimal path back to the source and r2 received a copy from r3 and since our - no longer wants to receive multicast traffic it's going to send a prune message just like we might take some pruning shears and literally cut a branch off of a tree we're going to prune off router r2 from this distribution tree we're going to send a prune message to r1 and r3 and rat r3 it no longer wants to receive multicast traffic from router r2 so it's going to send in a prune message and as a result we're left with an optimal tree the traffic goes from the server to router r1 which goes directly down to r3 which then goes out to our receiver now what if we had another receiver that comes on the or here comes another receiver router r2 just received an IGMP message saying that somebody connected off of one of its interfaces wants to receive traffic for 225 dot 1.2.3 and it's no longer a member of the tree what does it do well it's going to graft itself back on we send a graft message up to r1 saying can I be part of the tree again and that will be acknowledged and now r1 is going to send traffic both to r2 and r3 and they send it out to their attached receivers that's p.m. a dense mode but one of the drawbacks of that is that initially we flooded multicast traffic throughout our entire topology this was a smaller topology so we could better visualize it but think if we had dozens of routers and when a multicast source starts streaming that initial traffic gets flooded throughout the network that's called a flood and prune behavior that could impact network performance and in some implementations of a PIM dense mode that flooding and pruning happens about every three minutes that can dramatically impact Network performance on a larger network however some of the more recent implementations of PIM dense mode have a feature called state refresh so we don't have to do that flooding and pruning every three minutes but still it's considered a best practice to use PIM sparse mode as opposed to PIM dense mode sparse mode uses a shared distribution tree remember earlier we talked about the concept of a rendezvous point well here router r2 is acting as at rendezvous point and if my receiver wants to join the group of to twenty five one two three it's going to send its IGMP message up to router r3 and router r3 has knowledge of a rendezvous point in the network this is going to prevent that flooding and pruning behavior the multicast source comes up and it can send just two router R to anybody that wants to receive that traffic it can go request to that traffic from router r2 so the receiver it sends up an IgM P report message and then that router r3 it's going to send a join message up to router r2 now notice the way this is written star comma G the star represents the source we're saying we don't really care where we get it from we don't care what the source IP address is the group we want to join is 225 one two three that's the G and star comma G so now the multicast source is going to send traffic to the rendezvous point which is going to relay it down to r3 which then sends it out to the receiver well that's great that we avoided that flood and prune behavior however we've got a downside here that was not an optimal path to go from r1 to r2 to r3 it would have been much better if we just went from r1 directly down to r3 + r3 knows that r3 saw the source IP address of that multicast sender and it looked at its IP routing table and it determined that a more optimal path would have been the path from r1 so what are three is going to do it's going to send an Eskimo ji join up to r1 the S is the source because it now knows the source IP address of the sender it's going to say I want to receive traffic from this source destined for this group and then r1 is going to start sending it traffic directly down to r3 however notice the traffic also went to r2 to r3 to the receiver the receiver got two copies of the packet we no longer need that traffic from r2 so r3 sends a prune message up to r2 and now we've got an optimal path we're going from R 1 to R 3 to the receiver beautiful that is called shortest path tree switchover when we make that switch over from the rendezvous point to the shortest path tree the most optimal path so we ended up with an optimal path and we did not have to do flooding and pruning which could be really negative on a large network that's the reason we say that PIM sparse mode is preferred over PIM dense mode and now that we've talked a lot about the theory of multicast let's go out to a live interface and let's do some multicast configuration I want to show you how we set up PIM dense mode first of all then we'll set up PIM sparse mode where we go to each of the routers and we tell the routers hey here is the IP address of the rendezvous point and then I want to show you a trick to make things a little bit easier for us we don't have to go to all of the routers in a network and say here's the IP address of the rendezvous point here's the IP address of the rendezvous point it would be much better much more efficient much more resilient if rendezvous points could advertise their availability to the network that's a feature called Auto RP I want to show you how to set that up but let's get started at a live interface by setting up a basic PM dense mode configuration let's begin our multicast configuration on router r1 we're go into global configuration mode and we need to enable multicast routing on this router to do that for IP version 4 that's what we're going to be doing in this demonstration I want to say IP multicast - routing if I were setting this up for IP version 6 it would be ipv6 multicast routing but again we're going to do an IP version 4 demonstration now I need to go into each of my interfaces that I want to participate in multi casting and enable them for multi casting and I'm going to do that by specifying the PIM mode remember we talked about dense mode and sparse mode first let's set this up for dense mode we're going to interface fastethernet 0/0 and we'll say IP pim dense - mode let's do that for interface fastethernet 0/1 as well i ppm dense mode let's do it for interface and fast ethernet 2/0 will say IP PIM dense mode and we've configured router r1 for IP p.m. at dense mode operation let's go to router r2 and we'll do a similar configuration I'll say IP multicast - routing and I'll go into interface at Feist Ethernet 0/0 and I'll say IP pim dense mode let's do that for interface fastethernet 0/1 as well and let's move on to router r3 in global configuration mode again will say IP multicast - routing and we'll go into interface fastethernet 0/0 and I'll say IP pim dents - mode will do that for a fastethernet 0/1 and for interface fastethernet - / 0 IP PM dense mode and we've now configured multicast routing on all of these routers well routers r1 r2 and r3 the multicast a source that you see on screen I'm actually going to be using a router for that and the receiver I'm going to be using a router for that as well and before I start sending multicast traffic of the network here on router r3 let's give a show come and let's say show IPM route instead of looking at the unicast IP writing-table we're looking at the multicast IP writing-table and right now we don't have any entries except for this one that gets entered automatically this is used for auto RP we could automatically learn the IP address of a rendezvous point and I'll demonstrate that for you in just a bit now let's set up some multicast traffic I'm going to go to my multicast source and let's start a ping I'm going to ping with a destination address of a multicast address I'm going to do a ping to 2:39 dot one dot one dot one and I will repeat it a lot of times I'll say nein nein nein nein nein nein nein nein nein that's going to send a lot of pings great now let's go set up the receiver to receive those pings we'll go to the receiver and say I want to join the group to 39.1 dot one dot one here's how I can do that let's go into interface fastethernet 0/0 and I'll say IP IGMP join - group 239 dot one dot one dot one this is going to cause this router acting as a PC to send an IgM P join message up to router r3 saying hey I want to receive traffic destined for 239 1.1.1 and I'm curious what our multicast IP writing table looks like now let's go back to our three and let's once again do a show IP M route oh look at this we now have what's called an S comma G entry by the way for every s comma G entry there's a corresponding star comma G entry the star meaning any source associated with this group but we know of a specific source we're getting the multicast traffic sourced from at 10.1.1.10 so this is an S comma G entry that's the source that's the group we can also look at this output and determine what is the ingress interface for the multicast traffic it's coming into what interface well we can see the incoming interface for this s comma G entry is a fastethernet 0/0 that's coming in from router r1 we can also see our outgoing interface or interfaces we've just got one this is called the oil the o IL the outgoing interface list we see that we're going out a fastethernet 2/0 and finally noticed the flags on this Eskimo GN tree just notice for now that we do not have the J flag set the J flag says that we have joined the shortest path tree we are using the shortest path tree but because we're using dense mode we started out with the shortest path tree we didn't have to join it so there's no J entry here that's going to be different let's reason I'm pointing it out now it's going to be different when we set up in sparse mode in fact let's do that now let's set up him sparse mode let's go back and revisit router r1 and remember p.m. sparse mode is going to use a rendezvous point let's make a router r2 our rendezvous point and one way for routers to know about that rendezvous point is to statically configure the rendezvous point let's do that on router r1 I'll say IP pam RP - address and again if I were doing this with IP version 6 it would be ipv6 p.m. RP - address IP PRP address 2.2 2.2 I'm using the loopback interface of router r2 because a loopback interface doesn't go down based on changing Network conditions now let's go into each of our other interfaces on r1 and say that we want to run pim sparse mode I'll say interface fastethernet 0/0 IP Pam sparse mode let's do it again for fastethernet 0/1 IP PM sparse mode and interface fastethernet 2/0 IP PM sparse mode great now let's go to router r2 this is going to be our rendezvous point I'm going to say IP PIM RP address is 2 2 2 2 let's go into loopback 0 and say we want to run IP pim sparse mode let's go into interface fastethernet 0/0 say the same thing and finally for interface fastethernet 0/1 now let's set up router r3 i'll say that my rendezvous point is 2 2 2 2 let's go into fastethernet 0/0 and say IP pim sparse mode let's do it again for fastethernet 0/1 and finally for interface fastethernet 2/0 IP PM sparse mode now let's check our multicast state here on router r3 once again I'll do a show IP in route and you'll notice that this looks really similar to what we had with pim dense mode however notice that this s comma G entry that we have right here it does have the je flag set we did not have the je flag said earlier the je means that we have joined the shortest path tree we did SPT switchover in other words remember how that worked we stopped receiving traffic from the rendezvous point and we started receiving traffic via the optimal path that was the SPT join and we see that that has happened here so without the flooding and pruning behavior we're getting traffic via an optimal path in fact let's go back to router r2 our rendezvous point for a second let's take a look at its multicast IP writing-table let's do a show IP in route here and notice this s comma G entry we're receiving traffic from the multicast ascender but because we've done shortest path tree switchover we're no longer sending it to anyone for a very brief moment we were sending it down to r3 and then it did SBT switch over and we can see that we're not sending it to anybody else because look at the oil the outgoing interface list is no we're not sending it to anyone but we are receiving traffic coming in from router r1 via fastethernet 0/0 and in this example we saw how to tell the routers in a topology who was the RP however there's an easier way especially if we have a large topology we can have the rendezvous point and announce itself as the RP there are a couple of processes at work here we need to have an RP and we need to have a mapping agent a mapping agent listens to group 2 24.0 139 it's listing for any router announcing itself as an RP and the mapping agent then resolves any conflicts that might exist among these routers that want to be RP s and this mapping agent announces the multicast group Arpi mapping to the group of 224 0.40 you see this entry it was appearing in all of our routers as soon as we enabled multicast routing we're going to be announcing to this multicast group that the rendezvous point for the group of 239 1.1.1 the rendezvous point is 2 2 2 2 now in our case router r2 it's going to act as both of the mapping agent and the RP so we need to go to each router and remove the information about the RP also we need to change our Pam mode from sparse mode to sparse dense mode the reason is we've got a bit of a paradox here you see our routers need to use multicast to identify the RP however how can we listen in to this group if we're not running multicast we cannot run pim sparse mode until we know the RP and we cannot learn their RP until we listen in to this group well what if we could do this what if we could run dense mode just long enough to listen in to this group and learn the address of the rendezvous point then we can switch over to sparse mode that's an option we could run sparse dense mode which says run in sparse mode if you can run in dense mode if you cannot so we're going to use dense mode to learn the identity of the RP e then we'll switch over to sparse mode let's go to each of our routers remove the rendezvous point configuration and change the PIM mode for each interface then we'll configure Auto RP let's start on router r1 let's say that we want to get rid of our statically configured PM RP address I'll say no IP p m RP address 2 2 2 2 and let's go into interface fastethernet 0/0 and let's say that our PIM mode is sparse dense mode same thing for face to thir net 0 / 1 sparse dense mode and for a fast ethernet 2 / 2 0 sparse dense mode now let's go to router r2 and in global configuration mode will say no IP m RP address 2 2 2 2 will go into interface fastethernet 0/0 and we'll say IP pim sparse dense mode same thing for a fastethernet 0/1 and same thing for our loopback interface finally we go to router r3 do the same thing no IPP m RP address 2 2 2 2 let's go into interface fastethernet 0/0 and say IP pim sparse dense mode based Ethernet 0 / 1 I PP M sparse dense mode based Ethernet 2 / 2 0 IP p.m. sparse dense mode and now that we've set everybody up to learn the RP automatically we need to go to router r2 and configure it to automatically announce its availability as an RP and we also need to configure it as a mapping agent let's go to router r2 and we'll say IP Pam send RP announced now we're going to be announcing that our loopback 0 interface is the RP it's two - two - how far do I want to advertise this across how many router hops well we can set a time to live value here we can say that the scope is 16 meaning that I'm going to be setting my advertise my time to live value to 16 remember that the time to live the TTL value gets decremented every router hop and once it reaches 0 its discarded so I'm going to be able to span several routers with my advertisement saying hey I'm the RP and we want our mapping agent to be able to hear that information and I misspelled announce let's fix that that's better let's now configure the mapping agent by saying IP pim send RP discovery again I'll set the scope to 16 so router r2 is now going to be listening for anybody advertising itself as the RP and it's going to be able to resolve any conflicts and then advertise that information out to 224 0.1 dot 40 and we've also said that r2 is willing to be at an RP it's advertising its availability and it's using loopback 0 as the RP address now that we've done that let's go over to router r3 and see what multicast groups we know about let's do another show IP m route and we've got several entries here notice that we now have an Eskimo G entry full tu-tu-tu-tu-tu-tu 2401 39 give this command one more time and there so we've got this additional s comma G entry 10 dot 1.4.2 for this well-known group of 224 0.1 dot 40 what we're saying here is we're learning information from 10 dot 1.4.2 we're learning from our mapping agent in other words about an RP and then RP that we learned from this group is 2 2 2 2 we can get further confirmation about who is the RP by doing a show i peep m RP command and it tells us very clearly that for group 239 dot 1.1.1 we're using a rendezvous point of 2.2 to 2 and this also tells us that we're running Pym version 2 and speaking of Pym version 2 I'm not going to take time to configure it because it's so similar to auto RP but I want you to be aware that there is an alternative to using auto RP specifically if all the routers are running app in version 2 you can configure something called to be SR that's an abbreviation for bootstrap router now with BS r you configure BS are candidates that similar to the RP announced configuration that we gave on router r2 and you can also configure be SRS those are similar to mapping agents that's going to work very similar to Auto RP cisco came out with the auto RP solution before the standards bodies came out with BS r but they work basically the same all right that is your look at multicast we started with the basic saying why do we need multicast why is it better than broadcaster unicast in some situations we talked about the addressing with IP version 4 with IP version 6 we saw how to take an IP version for multicast IP address and convert that into a corresponding multicast MAC address we saw how the RPF check worked we talked about IGMP versions 1 & 2 & 3 we contrasted PIM dense mode with PIM sparse mode then we came out to a live interface and we saw how to configure PIM dense mode then we saw a couple of ways of how to configure Pam sparse mode 1 where we go to each of the routers and we say here is the IP address of your rendezvous point and finally we took a look at a way that that rendezvous point information could be advertised using auto RP if you want to learn even more about Cisco routing and switching technologies just click the link in the description or on the right side of the screen and I'll send you more training videos and also if you don't miss any of my youtube videos be sure and subscribe thanks for watching and I'll see you next time

Channel: Kevin Wallace Training, LLC

Views: 147,386

Rating: 4.9432755 out of 5

Keywords: cisco, multicast, multicasting, multicast routing, ccna, ccnp, ccnp tshoot 300-135, ccnp switch 300-115, ccnp route 300-101, ccnp certification, ccie, routing and switching, ccnp lab, #kwtrain

Id: Gjt2L9jAYNA

Length: 42min 44sec (2564 seconds)

Published: Tue Apr 19 2016