MVPN Video 1 – Introduction to Multicast VPNs (MVPN) with Rosen-GRE/MDT-GRE

MVPN Video 1 - Introduction to Multicast VPNs (MVPN) with Rosen-GRE/MDT-GRE

hello and welcome to decoding packet dot infos multicast VPN video series in this very first video of this video series we are going to be covering basic ROS and GRE model or also called the GRE based MDT model nowadays or the multicast distribution tree now this is a fairly advanced level video series so there are some prerequisites unfortunately to this there are some things you need to bring to the table already in order to enhance your understanding of multicast VPNs one of the very first things you should be pretty comfortable with IP multicast itself so decoding packet dot in for itself has a introductory series on on IP multicast and if any of these terms sound unfamiliar to you I would highly recommend that you go back and watch that series first before coming back to this one so things like protocol independent multicast any source multicast and source-specific multicast are absolute prerequisites and you must know them in order to understand the material that are going to be discussed in this video series things like PIM by directional or by der they're optional but they would definitely enhance your understanding of what is being discussed in this lecture series the second thing is basic understanding of MPLS so you should not be stumped by terms such as LS B's what is LD P and for example you should at least know what is RSVP traffic engineering although it is an optional topic but it is something that will be mentioned and you should have a decent understanding of these topics finally you should have a thorough understanding of how MPLS layer 3 VPN swerd because what we are going to do is all of the multicast VPNs they will be built on top of the traditional MPLS layer 3 VPN and if you do not understand that frankly you will not be able to follow much of what is being discussed in this particular lecture series so it is assumed that you know the details of the PE and the P functionality how the provider edges and how to provide our routers work and what are their functions in a given system it is also assumed that you understand the basic PE to see routing techniques so for example how is OSPF use between the Pease to see our BGP is used and how any of the other protocols will be used we may not be going in-depth a lot of that but there's definitely going to be a PE to seee protocol already running on top of that we build the multicast VPN so what is multicast VPN or what is a multicast VPN the basic idea is to provide IP multicast transit services to SP customers in addition to the layer 3 VPN services they are already receiving so with the layer 3 VPN services you're providing a unicast transit path to the customers with M VPN you're also going to provide them a multi gas transit path or transit services across the same SP core so for example if a if the customer has a receiver or several receivers in site number two of the same VPN and then there is a sender in site one of the same VPN the receivers then should be able to signal to the seller to send the traffic and finally the sender should be able to send the traffic across the same SP core that the layer 3 VPN is working on but in a multicast fashion most often what is going to happen with M VPN is we are going to take the customers same protocol independent multicast and from this point on we will definitely call it C pin so this is going to be something that comes is going to be this is going to be used often enough but C pin is from this point on going to refer to the pin that is running at the customer sites so if you have three customer sites and they all run BAM then these are all instances of CPM and what the multicast VPN is going to try to do or accomplish to do is have the CPM work across the SP core so you should be able to signal them across the SP core the BES the provider edge routers will transport C pin messages across the SP core now how they do this those are actually the nitty-gritty details of em VPN sometimes it is tunnel sometimes it is translated to a different third of message but rest assured there are various various methods available to the bees and all of them serve to get these CPM signaling or sleeping messages across the SP core so to that extent the PE S will run the CPM instances inside the vrf context so each of the bees in addition to running a routing protocol unicast routing protocol they will also be running c p– him inside the vrf and what's going to happen then because they are running CPM inside the vrf they are going to form CPM neighbor relationships with the CES with their respective CES that they are connected to so for example when you look at a show IP bim neighbor show command inside the vrf you will see that the PE is adjacent to the c and then they're going to get all of these signaling inside at least the vrf and try to get it across the SP core an important thing to note here the SP may also be running its own them so the SP core may also be running multicast in its own core and from this point on for this lecture series that would be called ppm or provider pim so it is completely a different protocol than CPM it runs in the multicast table or the global context while sipping will run inside the customers vrf but the distinction between the two of them is extremely important and you should always take care to call CPM CPM and then provide a pim deepam that then brings us to the very first model that is available as an option for M VPNs and this is the Rosen model or the rosen multicast distribution tree are also simply nowadays called the multicast distribution tree or MDD the name Rosen comes from the famous network engineer Eric Rosen who is responsible for a plethora of RFC's for the IETF the most notable amongst them is the basic MPLS RFC and the MPLS layer 3 VPN RFC but there are also a bunch of others including this one so this started off as a document called draft frozen and internet draft and it was later turned into a historic RFC RFC 60-37 so all of the details for this are available in RFC 60-37 and what it is using or what it is doing is it is treating the SP core as if it was a LAN so the protocol auto-discovery via multicast is already widely used by a number of different protocols so for example OSPF routers on a broadcast segment they discover each other using IP multicast so each of the OSPF routers sends hellos on to 2400 v and they're also listening for their neighbors hellos on to 2400 v this allows you without any explicit configuration to create an OS because network where the routers auto-discovery each other they form a Jason C's with each other they do all of the OSPF things with each other but without any specific configuration except just earning OSPF on on that particular broadcast link what Rosanna MDT or draft rosen is going to do is it's going to use the same sort of fundamentals to extend see them across the SP core so for example this is your SP core with three PE s they are all connected to three CES and they're probably running pin with those CES and what's going to happen then is that vrf bounded pin the CPM is then going to be extended across the SP core and in essence this SP core is going to sort of vanish from a multicast point of view and what's going to be left is a an SP core that peepin or CPM treats as if it was a LAN so it also allows the PE routers to order discover each other and at the end of the day all of these PE routers they're going to become adjacent with each other these routers are all going to be been adjacent with each other so in a sense what's happening here is the CPM signaling is it's overlaid on the SP core so you're running seeping on top of the SP core but transparent to the SP core so you need a transport you need a transport to get the PIM packets from for example from PE ones vrf to PE twos v RF + 2 p3 s v RF so you need to tell these packets somehow originally MPLS was not an available option so even though you're using MPLS for the unicast routing tape or for the unicast packets for the multicast packets it was actually just multicast that was used in the SP core so you would use P multicast to get the packets across the multicast core from one PE to another PE and this was true for both control and data packets so the pin packets or the control packets were encapsulated the same way the data packets the actual multicast traffic was encapsulated however currently there is a pure MPLS option that is available for transport so now you can use MPLS in the core without having to run IP multicast in the core to get the the data packets and the control packets across so what PIM then does is it uses multi multi-point GRE as a transport so I'm hoping at this point you're familiar with what unicast GRE is if not go brush up on that but what's the difference between unicast GRE and multicast or multi-point GRE is multi-point GRE uses instead of a unicast routing address its destination IP address is an IP multicast group so it is the same packet but the destination IP instead of being just a unicast IP for a point point tau for a point to multi-point tunnel the destination is an IP multicast group all of the interested bees will this will join this pre-decided group so you have to decide which group is going to carry the traffic from PE to PE but once that group has decided you program that group on the PE s and then they go ahead and they join that group they are receivers on that group there are also senders on that group but through the multicast core you use peepin or provider them to signal this group so that's how all of the routers know where the rendezvous point is and how to build that tree but the resulting multi-point to multi-point tree because remember all of the bees are also senders and they're also receivers so this tree is not a point multi-point tree in essence it is a multi-point to multi-point tree or think of PIM by Durr when you think about this this is called the default multicast distribution tree it is nothing more than in IP multicast tree but it happens to have all of the all of the PE s as senders and also as clients now data traffic and use the same default MDT and by default if you don't do anything else that's what it does but it may not be the most optimal choice so this is something that is much more relevant or becomes much clearer when we go to the actual configuration and take a look at that but for right now remember that multi-point GRE tunnels are going to be used and all that the PE s are going to become pin adjacent with each other the details of this are up next in our next lecture which is going to be rosin GRE or MD MD T GRE and it's implementation on iOS and iOS X are once again we thank you for being with us and we hope that you would join us for the next lecture


Leave a Reply

Your email address will not be published. Required fields are marked *