THIS WEEK: DEPLOYING BGP MULTICAST VPNs, 2ND EDITION The networking industry has been looking for the best way to offer Multicast VPN services while leveraging the strength and scalability of the existing BGP/MPLS VPN technology The result of Junos® Networking Technologies several years of effort is Multiprotocol BGP Multicast VPN, often referred to as BGP MVPN This next generation technology has received a warm welcome in the market and is already deployed in many production networks, from Tier-1 service providers to financial and trading companies This Week: Deploying BGP Multicast VPNs assumes the reader has at least some experience with IP/MPLS architectures, including Multiprotocol BGP and IGPs You are not expected to be an expert in multicast as the basic concepts are revisited in the book, but if you are THIS WEEK: DEPLOYING BGP MULTICAST VPNs, 2ND EDITION already familiar with BGP/MPLS IP VPNs, you will find this book easier to read Whatever you bring to this seminar in a book will only be amplified by its clear explanations, explicit examples, and attention to detail The author walks you step-by-step through an advanced technology, thoroughly exploring a design that can be stood up in a week Roll up your sleeves and let’s get down to work “This excellent book is an ideal way to bring you up to speed on BGP Multicast VPN technology The book is a very practical guide, clearly describing the theory while showing the reader exactly how to configure the network using Junos It’s highly recommended!” Julian Lucek, Distinguished Systems Engineer, Juniper Networks LEARN SOMETHING NEW ABOUT JUNOS THIS WEEK: Build a BGP Multicast VPN working solution from scratch Configure and operate dynamic Point-to-Multipoint MPLS Label Switched Paths, with and without Traffic Engineering features Describe the integration of Customer PIM instances with VPNs, both in Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) scenarios Design an optimal distribution of Inclusive and Selective tunnels Find the right balance between control and forwarding plane efficiency Use Route Target policies to achieve partial mesh topologies of MVPN sites Build a BGP Multicast VPN solution this week Understand the clean decoupling of control and forwarding planes in BGP MVPN Published by Juniper Networks Books www.juniper.net/books ISBN 9367792220 789367 792223 52000 07500209 By Antonio Sánchez Monge THIS WEEK: DEPLOYING BGP MULTICAST VPNs, 2ND EDITION The networking industry has been looking for the best way to offer Multicast VPN services while leveraging the strength and scalability of the existing BGP/MPLS VPN technology The result of Junos® Networking Technologies several years of effort is Multiprotocol BGP Multicast VPN, often referred to as BGP MVPN This next generation technology has received a warm welcome in the market and is already deployed in many production networks, from Tier-1 service providers to financial and trading companies This Week: Deploying BGP Multicast VPNs assumes the reader has at least some experience with IP/MPLS architectures, including Multiprotocol BGP and IGPs You are not expected to be an expert in multicast as the basic concepts are revisited in the book, but if you are THIS WEEK: DEPLOYING BGP MULTICAST VPNs, 2ND EDITION already familiar with BGP/MPLS IP VPNs, you will find this book easier to read Whatever you bring to this seminar in a book will only be amplified by its clear explanations, explicit examples, and attention to detail The author walks you step-by-step through an advanced technology, thoroughly exploring a design that can be stood up in a week Roll up your sleeves and let’s get down to work “This excellent book is an ideal way to bring you up to speed on BGP Multicast VPN technology The book is a very practical guide, clearly describing the theory while showing the reader exactly how to configure the network using Junos It’s highly recommended!” Julian Lucek, Distinguished Systems Engineer, Juniper Networks LEARN SOMETHING NEW ABOUT JUNOS THIS WEEK: Build a BGP Multicast VPN working solution from scratch Configure and operate dynamic Point-to-Multipoint MPLS Label Switched Paths, with and without Traffic Engineering features Describe the integration of Customer PIM instances with VPNs, both in Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) scenarios Design an optimal distribution of Inclusive and Selective tunnels Find the right balance between control and forwarding plane efficiency Use Route Target policies to achieve partial mesh topologies of MVPN sites Build a BGP Multicast VPN solution this week Understand the clean decoupling of control and forwarding planes in BGP MVPN Published by Juniper Networks Books www.juniper.net/books ISBN 9367792220 789367 792223 52000 07500209 By Antonio Sánchez Monge Junos® Networking Technologies This Week: Deploying BGP Multicast VPNs, 2ND Edition By Antonio Sánchez Monge Chapter 1: Introducing BGP Multicast VPN Chapter 2: BGP Multicast VPN with PIM SSM as PE-CE Protocol 33 Chapter 3: BGP Multicast VPN with PIM ASM as PE-CE Protocol 59 Chapter 4: Selective Trees for Bandwidth Optimization 75 Appendix 85 ii © 2012 by Juniper Networks, Inc All rights reserved Juniper Networks, the Juniper Networks logo, Junos, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc in the United States and other countries Junose is a trademark of Juniper Networks, Inc All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners Juniper Networks assumes no responsibility for any inaccuracies in this document Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are owned by or licensed to Juniper Networks: U.S Patent Nos 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312, 6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785 Published by Juniper Networks Books Writer: Antonio Sánchez Monge Technical Review: Julian Lucek, Yakov Rekhter, Miguel Barreiros, Efrain Gonzalez Editor in Chief: Patrick Ames Copyeditor and Proofreader: Nancy Koerbel J-Net Community Management: Julie Wider This book is available in a variety of formats at: www.juniper.net/dayone Send your suggestions, comments, and critiques by email to: dayone@juniper.net Version History: First Edition, May 2011 Version History: Second Edition, May 2012 ISBN: 978-1-936779-22-2 (print) Printed in the USA by Vervante Corporation ISBN: 978-1-936779-23-9 (ebook) Juniper Networks Books are singularly focused on network productivity and efficiency Peruse the complete library at www.juniper.net/books 10 #7500209-en About the Author Antonio “Ato” Sanchez Monge (JNCIE-M #222 and CCIE #13098) holds a MS in Physics and a BA in Mathematics from the Universidad Autonoma de Madrid (UAM) He joined HP back in 1999 to specialize in networking support, then moved to Juniper Networks in 2004, where he is currently working at the Professional Services team During the last decade, Ato has been involved with projects for different ISPs in Europe Author’s Acknowledgments I would like to thank: Patrick Ames, my great editor, for his continuous encouragement and positive attitude throughout the nine-month cycle that this book took to be born; Julian Lucek, whose technical review uncovered key implementation details that I was not aware of; Yakov Rekhter for spotting some mistakes and motivating the second version of this book; Miguel Barreiros for sharing his insight on how to structure a technical book targeted to a diverse audience; Efrain Gonzalez, whose thorough review definitely helped to make this text clearer; Anton Bernal for introducing me to the Day One program and for his restless knowledge-sharing passion; all the readers of the first edition who provided feedback, from Lorenzo Murillo who patiently built the lab scenarios in Junosphere and in real routers, to my father who did his best to understand the first pages; and, all my colleagues at Juniper, as well as our customers, for bringing something new to learn every day Last but not least, I would have never written this book without the support of my family and friends, especially Eva, Manuel, and Lucas who supported my long writing hours “deep in the cave.” iii Welcome to This Week This Week books are an outgrowth of the extremely popular Day One book series published by Juniper Networks Books Day One books focus on providing just the right amount of information that you can execute, or absorb, in a day This Week books, on the other hand, explore networking technologies and practices that in a classroom setting might take several days to absorb or complete Both libraries are available to readers in multiple formats: Download a free PDF edition at http://www.juniper.net/dayone Get the ebook edition for iPhones and iPads at the iTunes Store>Books Search for Juniper Networks Books Get the ebook edition for any device that runs the Kindle app (Android, Kindle, iPad, PC, or Mac) by opening your device’s Kindle app and going to the Kindle Store Search for Juniper Networks Books Purchase the paper edition at either Vervante Corporation (www.vervante com) or Amazon (www.amazon.com) for prices between $12-$28 U.S., depending on page length Note that Nook, iPad, and various Android apps can also view PDF files If your device or ebook app uses epub files, but isn’t an Apple product, open iTunes and download the epub file from the iTunes Store You can now drag and drop the file out of iTunes onto your desktop and sync with your epub device What You Need to Know Before Reading You will need a basic understanding of Junos and the Junos CLI, including configuration changes using edit mode See the Day One books at www juniper.net/books for a variety of books at all skill levels This book assumes that you have the ability to configure basic IP connectivity, including interface addressing and static routes, and to troubleshoot a simple network as needed You should have at least some experience with IP/MPLS architectures, including Multiprotocol BGP and IGPs If you are already familiar with BGP/MPLS VPN technology, you will find this book easier to read You are not expected to be an expert in Multicast The basic concepts are revisited in the book The practical sections include hands-on tasks You are strongly encouraged to find a stable lab to practice iv iv After Reading This Book You’ll Be Able To Build a BGP Multicast VPN working solution from scratch Comprehensively choose among the available design options for Customer multicast routing and Provider transport Configure and operate dynamic Point-to-Multipoint MPLS Label Switched Paths, with and without Traffic Engineering features Understand the details of Provider Tunnel Auto-Discovery Describe the integration of Customer PIM instances with VPNs Explain the signaling involved in Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) scenarios Design an optimal distribution of Inclusive and Selective tunnels Find the right balance between control and forwarding plane efficiency Use Route Target policies to achieve partial mesh topologies between Multicast VPN sites Find an optimal placement of Customer Rendez-Vous Points in the ASM model Explain the differences between SPT-only and RPT-SPT modes List the different BGP Route Types supported for Multicast VPN Draw flow charts with the signaling steps Operate and troubleshoot the BGP MVPN solution effectively Explain in detail the differences between draft-rosen and BGP Multicast VPN Understand the clean decoupling of control and forwarding planes in the BGP-based solution MORE? An excellent source of information for how to deploy MPLS is This Week: Deploying MPLS, available at www.juniper.net/dayone MORE? An excellent source of advanced MPLS topics can be found in MPLS-Enabled Applications, Third Edition, by Ina Minei and Julian Lucek (2011, Wiley & Sons Publishers) You can get more information on this best-selling MPLS book at www juniper.net/books MORE? Another excellent source for further reading is Deploying Next Generation Multicast-enabled Applications: Label Switched Multicast for MPLS VPNs, VPLS, and Wholesale Ethernet, by Vinod Joseph and Srinivas Mulugu (2011, Morgan Kaufmann) For more information see www.juniper.net/books Chapter Introducing BGP Multicast VPNs IP Multicast Refresher BGP/MPLS VPN Refresher 15 Past, Present and Future in Multicast VPN 21 Deployment Options for BGP Multicast VPN 29 Answers to Try It Yourself Sections of Chapter 31 This Week: Deploying BGP Multicast VPNs, 2ND Edition Following upon the huge success of Unicast BGP/MPLS VPN solutions, the networking industry has been looking for the best way to offer Multicast VPN services while leveraging the strength and scalability of the existing unicast technology The result of several years effort is Multiprotocol BGP Multicast VPN, often referred to as BGP MVPN This technology has received a warm welcome in the market and is already deployed in many production networks, ranging from Tier-1 service providers to financial and trading companies The first chapter of this book introduces this state-of-the-art solution and explains how it differs from the other Multicast VPN flavors NOTE This book does not assume you to be an expert in both IP Multicast and BGP/MPLS, so the chapter begins with a basic concept refresher Even if you are already familiar with both topics, you should read the introductory sections to understand the differences between draft-rosen and BGP Multicast VPN After the basic theoretical introduction, a comprehensive description of the different Multicast VPN solutions is provided The flexibility of the Junos BGP Multicast VPN implementation makes it difficult to thoroughly cover all the configuration alternatives in any single book, so among the existing transport options, RSVP P2MP LSPs are used to illustrate the technology throughout the practical sections One last item This book focuses on IPv4 BGP Multicast VPN, but the concepts and technology are fully portable to IPv6 BGP Multicast VPN, also supported by the Junos operating system IP Multicast Refresher Multicast traffic flows from a given source (S) to a group (G) of receivers, as compared to unicast traffic, which is destined to a single receiver The forwarding path used to transport multicast is typically modeled as a tree, with the source being the root and the receivers sitting at the leaves Traffic is replicated by the routers at the branching points of the tree, so the structure is often referred to as a multicast distribution tree, or more simply, multicast tree The tree is represented upside down, with the sources on top and the receivers at the bottom, so the traffic flows down, much like water in a river With this picture in mind, the terms upstream and downstream are equivalent to towards the source and towards the receivers, respectively Multicast routing protocols are required to transport multicast traffic in networks where not all receivers sit in the same network segment as the source When this is the case, the router directly connected to the source is called the first-hop router, while the last-hop routers are directly connected to the receivers If the source and a receiver are both directly connected to the same router in different network segments, the first-hop router is also a last-hop router Multicast packets have an unicast source address and a multicast destination address With IPv4 addressing in mind, multicast IP addresses are encompassed by the 224/4 prefix, namely addresses from 224.0.0.1 up to 239.255.255.255 An IP Multicast group G is associated to a unique IP Multicast address Not all these addresses are routable, particularly 224.0.0.1 up to 224.0.0.255, which are link-local addresses typically used by several protocols for local signaling For example, OSPF hello packets have destination IP addresses 224.0.0.5 or 224.0.0.6 Chapter 1: Introducing BGP Multicast VPNs Internet Group Management Protocol (IGMP) IGMP is the protocol used by the final receivers to report multicast group membership to their directly-attached gateways, which become last-hop routers from the perspective of the multicast tree An IGMP group membership message expresses the desire to receive traffic destined to a multicast group A single receiver can subscribe to one, or several, multicast groups, and has the option to specify the sources that it is expecting the traffic to arrive from The routers send periodic IGMP Queries to the network segment, and the receiving hosts answer with IGMP Reports describing their group membership In case there are several IGMP routers in a segment, one of them is elected as the Querier (by default, the lowest IP address wins) A receiver can spontaneously send a Query or Leave packet when it first subscribes to, or unsubscribes from, a multicast group There are three IGMP versions: IGMPv1: This is a legacy version, most applications not use it anymore IGMPv2: The most commonly used version, IGMPv2 supports group-specific Queries and receiver-initiated Leaves IGMPv3: This version also supports source-specific Queries, Reports, and Leaves As an alternative to learning group membership dynamically from receiving hosts, Junos allows for the configuration of static IGMP reports in downstream interfaces, if required or if needed Any Source Multicast (ASM) and Source Specific Multicast (SSM) When an IGMPv1 or IGMPv2 receiver host joins a multicast group, it sends a (*, G) Report The G stands for a multicast group, or IP Multicast address, while the asterisk (*) is the wildcard sign, and refers to any source sending traffic to group G This model is known as Any Source Multicast (ASM) ASM is quite simple for the receiver applications – they just need to subscribe to a group address The complexity is in the IP network, as here the last-hop routers need to find a mechanism to join the multicast distribution tree without really knowing in advance what sources are active for a given group In other words, the network is responsible for converting (*, G) reports into (S, G) states A frequent question for those new to multicast is how the IP network handles the case where two different sources (S1 and S2) send traffic to the same group The answer is the network treats the (S1, G) flow independently from the (S2, G) flow Both arrive to the receiver, and it is up to the receiving application to consider each flow as independent (for example, two different video streams) or redundant copies of the same channel This latter case is the most common when a (*, G) state is created by the receiver In the Source Specific Multicast (SSM) model, the receiver application has a process to know in advance the source IP addresses, for example, via a web portal The receiver then sends an IGMPv3 source-specific (S, G) report, and the last-hop router knows what sources to pull traffic from – it’s a model that’s simpler for the network but more complex for the end-user application MORE? Refer to RFC 2236 and RFC 3376 for more information on IGMPv2 and IGMPv3, respectively Reading RFC 3569 is also recommended as it describes the SSM model from a general standpoint All can be viewed at https://datatracker.ietf.org/ This Week: Deploying BGP Multicast VPNs, 2ND Edition Protocol Independent Multicast (PIM) PIMv2 is the industry de facto IPv4 Multicast routing protocol PIM is responsible for building multicast distribution trees connecting sources to receivers, and needs to be enabled on all the router interfaces involved in multicast routing TIP If it helps, you can think of IGMP as the protocol between routers and hosts, and PIM as the protocol between routers All the PIM packets (except the Registers) are sent with the destination IP address 224.0.0.13, hence they are processed by all the PIM-enabled neighbors PIM adjacencies are established with the exchange of hello packets at the interface Once two routers are PIM neighbors on a link, they can exchange other PIM control packets The most important PIM control packet type is the Join/Prune, which contains a Join list and a Prune list These are lists of multicast source and group addresses PIM Join/Prune packets with an empty Prune list are commonly referred to as Joins, whereas those with an empty Join list are called Prunes When a router has downstream (S, G) receivers and is not connected to the (S, G) distribution tree, it typically, if running in sparse mode, sends a (S, G) PIM Join in the direction to the source S The upstream PIM neighbor first updates its outgoing interface list for (S, G) traffic, including the link at which the Join was received Then if it is not part of the (S, G) distribution tree yet, sends the (S, G) PIM Join to the next upstream router This process is repeated until the PIM Join reaches the distribution tree and/or the first-hop router If the downstream (S, G) state is lost, say, due to loss of IGMP membership at the last-hop routers, a (S, G) PIM Prune is sent upstream to cut the branch off the multicast distribution tree An important aspect of the PIM protocol is its soft-state nature, meaning that the multicast forwarding state is maintained by periodically sending the relevant PIM messages Downstream routers keep a set of refresh timers controlling the periodic generation of PIM Join and Prune messages upstream This refresh process keeps the multicast distribution tree active in steady state In this sense, PIM behaves unlike the highly-scalable unicast routing protocols such as OSPF, IS-IS, or BGP, which have a reliable information exchange mechanism and not require periodic control traffic flooding Multicast forwarding is more complex than unicast because it follows a tree structure with branching points and in order to avoid loops, it uses the RPF (Reverse Path Forwarding) mechanism Before forwarding an IP Multicast packet, the router checks whether the packet was received at the closest interface to the source (or, to the Rendezvous Point in certain cases) The process can be seen in Figure 1.1, where router C discards multicast traffic sourced from S if it is received via router B An IP unicast lookup is performed on the source address S, and if the next-hop points to the incoming interface, the packet is allowed for multicast forwarding This is the case for multicast packets sourced from S and arriving to router C via the direct link to router A The RPF check mechanism relies on IP unicast routing protocols – like static, RIP, OSPF, ISIS, or BGP – to populate the unicast routing table with routes towards all the potential multicast sources When PIM is used, the choice of unicast routing protocols is irrelevant, hence the independent in the Protocol Independent Multicast name 80 This Week: Deploying BGP Multicast VPNs, 2ND Edition 1:65000:200:10.101.1.1/240 * Self 100 I 3:65000:200:32:10.22.1.1:32:239.22.22.22:10.101.1.1/240 * Self 100 I user@PE1> show route advertising-protocol bgp 10.101.5.5 table white mvpn extensive | match “communities|pmsi” Communities: target:65000:22 PMSI: Flags 0x0: Label[0:0:0]: RSVP-TE: Session_13[10.101.1.1:0:31396:10.101.1.1] Communities: target:65000:22 PMSI: Flags 0x1: Label[0:0:0]: RSVP-TE: Session_13[10.101.1.1:0:51182:10.101.1.1] S-PMSI A-D route C-Source Length & Address “PE1” router ID (lo0.0 address) : 65000:200 : 32:10.22.1.1 : 32:239.22.22.22 : 10.101.1.1 VPN “white” RD Figure 4.3 C-Group Length & Address Format of a Type S-PMSI Auto-Discovery Route The Route Targets (RT) match the configured VPN white policies: a route originated by a Sender PE and targeted to all Receiver PEs, carries RT target:65000:22 The PMSI attribute in the I-PMSI and S-PMSI routes is practically identical The only change is the Tunnel ID, which is different NOTE The generation of a S-PMSI A-D route is driven by a pure control plane mechanism It is triggered by the reception of matching C-Multicast - Source/Shared Tree Join routes, and not by the (C-S, C-G) traffic Upon reception of the Type S-PMSI A-D route, PE3 sends a Type Leaf A-D route targeted to PE1 The format of this route is illustrated in Figure 4.4 Let’s first examine the output of the following commands at PE3 where you can see the format of a Type Leaf A-D route at work: user@PE3> show route advertising-protocol bgp 10.101.5.5 table white.mvpn white.mvpn.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path 1:65000:200:10.101.3.3/240 * Self 100 I 4:3:65000:200:32:10.22.1.1:32:239.22.22.22:10.101.1.1:10.101.3.3/240 * Self 100 I 7:65000:200:65000:32:10.22.1.1:32:239.2.2.2/240 * Self 100 I 7:65000:200:65000:32:10.22.1.1:32:239.22.22.22/240 * Self 100 I user@PE3> show route advertising-protocol bgp 10.101.5.5 table white mvpn extensive | match communities Communities: target:65000:2 Communities: target:10.101.1.1:0 Communities: target:10.101.1.1:6 Communities: target:10.101.1.1:6 Chapter 4: Selective Trees for Bandwidth Optimization Leaf A-D route Original S-PMSI A-D route 81 “PE3” router ID (lo0.0 address) : 3:65000:200:32:10.22.1.1:32:239.22.22.22:10.101.1.1 : 10.101.3.3 Figure 4.4 Format of a Type Leaf Auto-Discovery Route And here is an explanation of the different Route Targets used: I-PMSI A-D route: This route is announced by Receiver PEs and must be imported by Sender PEs According to VPN white configured policies and Figure 2.6, the RT is target:65000:2 Leaf A-D route: This route is targeted to PE1 only, so the RT target: 10.101.1.1:0 contains its Router ID C-Multicast – Source Tree Join route: This route is targeted to PE1 and VRF white The RT target:10.101.1.1:6 contains PE1 Router ID and a local identifier of the VRF Try It Yourself: Examine the Internal Policies Route Targets target:65000:2 and target:65000:22 have been configured in VRF white policies However, there are other RTs that also play their part in the solution At PE1, execute the commands show policy and show policy to answer these questions: What policy is responsible for importing Leaf A-D Routes? What policy is responsible for importing C-Multicast Routes into VRF white? What policy is responsible for setting Route Import communities to unicast (family inet) routes exported from VRF white? Forwarding in Selective Trees The technology chosen here for the Selective P-Tunnels is also based on RSVP P2MP LSPs, which you already explored back in Chapter At this point, there is one Inclusive and one Selective Tree rooted at PE1 for VRF white Let’s take a quick look at PE1: user@PE1> show rsvp session p2mp ingress Ingress RSVP: sessions P2MP name: 65000:200:mvpn:white, P2MP branch count: To From State Rt Style Labelin Labelout 10.101.3.3 10.101.1.1 Up SE – 303488 10.101.4.4 10.101.1.1 Up SE – 303488 P2MP name: 65000:200:mv1:white, P2MP branch count: To From State Rt Style Labelin Labelout 10.101.3.3 10.101.1.1 Up SE – 304272 /*** Lines related to black Inclusive Tree are ommited ***/ LSPname 10.101.3.3:65000:200:mvpn:white 10.101.4.4:65000:200:mvpn:white LSPname 10.101.3.3:65000:200:mv1:white 82 This Week: Deploying BGP Multicast VPNs, 2ND Edition As expected, the Selective Tree only has one leaf Now let’s look at PE3: user@PE3> show rsvp session p2mp egress Egress RSVP: 3 sessions P2MP name: 65000:200:mvpn:white, P2MP branch count: 1 To From State Rt Style Labelin Labelout LSPname 10.101.3.3 10.101.1.1 Up 0 1 SE 17 – 10.101.3.3:65000:200:mvpn:white P2MP name: 65000:200:mv1:white, P2MP branch count: 1 To From State Rt Style Labelin Labelout LSPname 10.101.3.3 10.101.1.1 Up 0 1 SE 17 – 10.101.3.3:65000:200:mv1:white /*** Lines related to black Inclusive Tree are ommited ***/ PE1 has a different next-hop for (10.22.1.1, 239.2.2.2) and (10.22.1.1, 239.22.22.22) C-Multicast routes, the first going to the I-PMSI, and the second to the S-PMSI just signaled Execute the following command at all PEs (PE1 and PE3 are shown here): user@PE1> show mvpn c-multicast instance-name white [ ] Legend for c-multicast routes properties (Pr) DS derived from (*, c-g) RM remote VPN route Instance : black MVPN Mode : SPT-ONLY C-mcast IPv4 (S:G) Ptnl St 10.22.1.1/32:239.2.2.2/32 RSVP-TE P2MP:10.101.1.1, 31396,10.101.1.1 RM 10.22.1.1/32:239.22.22.22/32 S-RSVP-TE P2MP:10.101.1.1, 51182,10.101.1.1 RM user@PE3> show mvpn c-multicast instance-name white [ ] Legend for c-multicast routes properties (Pr) DS derived from (*, c-g) RM remote VPN route Instance : black MVPN Mode : SPT-ONLY C-mcast IPv4 (S:G) Ptnl St 10.22.1.1/32:239.2.2.2/32 RSVP-TE P2MP:10.101.1.1, 31396,10.101.1.1 10.22.1.1/32:239.22.22.22/32 S-RSVP-TE P2MP:10.101.1.1, 51182,10.101.1.1 But the final proof is checking that PE3 is receiving the (10.22.1.1, 239.22.22.22) C-Multicast traffic, while PE4 is not Execute the following commands at PE3 and PE4: user@PE3> show multicast route instance white group 239.22.22.22 extensive | match pps Statistics: 18 kBps, 100 pps, 38285 packets user@PE4> show multicast route instance white group 239.22.22.22 extensive | match pps user@PE4> The output at PE4 may have one line with pps, if the entry has not expired yet from the cache Feel free to a more exhaustive control and forwarding plane check on your own test bed if you’re following along, as explained in Chapter TRY THIS Generate more flows and Selective Trees at VPN white Explore the flexibility of mapping C-Multicast traffic to S-PMSIs templates using network masks Chapter 4: Selective Trees for Bandwidth Optimization 83 MORE? In RPT-SPT mode, you can use the wildcard-source and wildcard-group-inet keywords to effectively map (*, C-G) or even (*, *) traffic to a S-PMSI This reduces the amount of signaling, as a single Selective P-Tunnel can transport many C-Multicast flows, at the expense of less bandwidth optimization A given (C-S, C-G) flow would be mapped to a PMSI in the following way, starting from the most preferred option if available S-PMSI configured for (C-S, C-G) S-PMSI configured for (*, C-G) S-PMSI configured for (*, *) Finally, I-PMSI You can check the details at [S-PMSI-WILDCARD] or, even better, try it! TRY THIS Up to a challenge? In the RPT-SPT mode example described in Chapter 3, you can prevent CE3 from initiating SPT switchover by setting its SPT threshold to infinity In that case, traffic was going from PE1 to PE3 via the Inclusive Tree, but what if PE1 uses Selective Trees in VPN black? Short answer: PE3 still joins the Selective Tree Long answer: give it a try! References [S-PMSI-WILDCARD] http://tools.ietf.org/html/draft-rekhter-l3vpn-mvpn-wildcard-spmsi Answers to Try It Yourself Sections of Chapter Try It Yourself: Examine the Internal Policies These are the answers to the three questions: vrf-mvpn-import-cmcast-leafAD-global-internal vrf-mvpn-import-cmcast-white-internal vrf-mvpn-export-inet-white-internal 84 This Week: Deploying BGP Multicast VPNs, 2ND Edition Appendix Initial Configuration of a CE Router 86 Initial Configuration of a PE Router 87 Initial Configuration of the P Router 89 Basic Connectivity Tests 91 What to Do Next & Where to Go 94 86 This Week: Deploying BGP Multicast VPNs, 2ND Edition This Appendix contains the initial configuration of each of the routers included in the test bed for this book Only the relevant sections for the Multicast VPN scenario are displayed: interfaces, protocols, policy-options, routing-options, and routinginstances Other generic information like system or management IP addresses are omitted, as they have no influence on the solution built here in this book, and would be different on your test bed anyway NOTE The hardware paths of the interfaces (like FPC and PIC slot numbers) are not important for the setup Using other types of access or core interfaces is also allowed, as long as the core links support vrf-table-label Initial Configuration of a CE Router All the CEs have nearly identical baseline configurations, except for the fact that different IP addresses are configured at the interfaces and static route hierarchies The configuration below corresponds to CE1 Please refer to Figure 2.1 in order to configure the other CEs interfaces { ge-0/0/1 { vlan-tagging; unit { vlan-id 101; family inet { address 10.11.1.2/30; } } unit { vlan-id 102; family inet { address 10.22.1.2/30; } } } ge-0/0/2 { vlan-tagging; unit { vlan-id 101; family inet { address 10.1.1.2/30; } } unit { vlan-id 102; family inet { address 10.2.1.2/30; } } } } routing-instances { black { instance-type virtual-router; interface ge-0/0/1.1; interface ge-0/0/2.1; routing-options { static { route 0.0.0.0/0 next-hop 10.1.1.1; } Appendix 87 } } white { instance-type virtual-router; interface ge-0/0/1.2; interface ge-0/0/2.2; routing-options { static { route 0.0.0.0/0 next-hop 10.2.1.1; } } } } Initial Configuration of a PE Router All the PEs have nearly identical baseline configurations, except for the IP and ISO addresses, static routes, and core interface hardware paths (i.e so-0/1/2 vs so-0/1/0) The configuration below corresponds to PE1 Please refer to Figure 2.1 in order to configure the other PEs interfaces { ge-0/0/2 { vlan-tagging; unit { vlan-id 101; family inet { address 10.1.1.1/30; } } unit { vlan-id 102; family inet { address 10.2.1.1/30; } } } ge-0/0/3 { unit { family inet { address 10.100.5.1/30; } family iso; family mpls; } } so-0/1/0 { unit { family inet { address 10.100.1.2/30; } family iso; family mpls; } } lo0 { unit { family inet { address 10.101.1.1/32; } 88 This Week: Deploying BGP Multicast VPNs, 2ND Edition family iso { address 49.0000.0000.0001.00; } } } } routing-options { router-id 10.101.1.1; autonomous-system 65000; } protocols { rsvp { interface ge-0/0/3.0; interface so-0/1/0.0; } mpls { interface ge-0/0/3.0; interface so-0/1/0.0; } } bgp { group RR { type internal; local-address 10.101.1.1; family inet-vpn { unicast; } neighbor 10.101.5.5; } } isis { level disable; interface ge-0/0/3.0 { level metric 50; } interface so-0/1/0.0; } ldp { interface ge-0/0/3.0; interface so-0/1/0.0; } } routing-instances { black { instance-type vrf; interface ge-0/0/2.1; route-distinguisher 65000:100; vrf-target target:65000:111; vrf-table-label; routing-options { static { route 10.11.1.0/30 next-hop 10.1.1.2; } } } white { instance-type vrf; interface ge-0/0/2.2; route-distinguisher 65000:200; vrf-import white-imp; vrf-export white-exp; vrf-table-label; routing-options { Appendix 89 static { route 10.22.1.0/30 next-hop 10.2.1.2; } } } } policy-options { policy-statement white-exp { term unicast { from family inet; then { community add white-target; accept; } } } policy-statement white-imp { term unicast { from { family inet; community white-target; } then accept; } } community white-target members target:65000:222; } NOTE If you’re wondering why VRF black includes a vrf-target statement, whereas VRF white has a set of vrf-import and vrf-export policies, the reason is explained in depth in Chapter Initial Configuration of the P Router There is only one P-router in the topology depicted in Figure 2.1 This is its initial configuration: interfaces { so-0/1/0 { unit { family inet { address 10.100.1.1/30; } family iso; family mpls; } } so-0/1/1 { unit { family inet { address 10.100.2.1/30; } family iso; family mpls; } } so-0/1/2 { unit { family inet { address 10.100.3.1/30; 90 This Week: Deploying BGP Multicast VPNs, 2ND Edition } family iso; family mpls; } } so-0/1/3 { unit { family inet { address 10.100.4.1/30; } family iso; family mpls; } } lo0 { unit { family inet { address 10.101.5.5/32; } family iso { address 49.0000.0000.0005.00; } } } } routing-options { router-id 10.101.5.5; autonomous-system 65000; } protocols { rsvp { interface all; interface fxp0.0 { disable; } } mpls { interface all; interface fxp0.0 { disable; } } bgp { group RR-CLIENTS { type internal; local-address 10.101.5.5; family inet-vpn { unicast; } cluster 10.101.5.5; neighbor 10.101.1.1; neighbor 10.101.2.2; neighbor 10.101.3.3; neighbor 10.101.4.4; } } isis { level disable; interface all; interface fxp0.0 { disable; } } Appendix 91 ldp { interface all; interface fxp0.0 { disable; } } } Basic Connectivity Tests Multicast VPN services rely on a stable unicast routing infrastructure Before configuring IP Multicast, it is important to verify that all routers have the necessary unicast routes, and to check end-to-end PE-CE and CE-CE reachability Unicast Routes and End-to-End Reachability at the CEs The CE routers just have a set of directly connected routes, as well as a default static route pointing to the directly attached PE: user@CE1> show route table black black.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, – = Last Active, * = Both 0.0.0.0/0 *[Static/5] 1d 03:22:40 > to 10.1.1.1 via ge-0/0/2.1 10.1.1.0/30 *[Direct/0] 1d 03:22:40 > via ge-0/0/2.1 10.1.1.2/32 *[Local/0] 1d 03:22:40 Local via ge-0/0/2.1 10.11.1.0/30 *[Direct/0] 1d 03:22:40 > via ge-0/0/1.1 10.11.1.2/32 *[Local/0] 1d 03:22:40 Local via ge-0/0/1.1 user@CE1> show route table white white.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, – = Last Active, * = Both 0.0.0.0/0 *[Static/5] 1d 03:22:40 > to 10.2.1.1 via ge-0/0/2.2 10.2.1.0/30 *[Direct/0] 1d 03:22:40 > via ge-0/0/2.2 10.2.1.2/32 *[Local/0] 1d 03:22:40 Local via ge-0/0/2.2 10.22.1.0/30 *[Direct/0] 1d 03:22:40 > via ge-0/0/1.2 10.22.1.2/32 *[Local/0] 1d 03:22:40 Local via ge-0/0/1.2 Once the unicast routes are verified, you can check the reachability of all the remote CEs Here is an example of a test between CE1 and CE2 for VPN black: user@CE1> ping 10.1.2.2 routing-instance black count 1 PING 10.1.2.2 (10.1.2.2): 56 data bytes 64 bytes from 10.1.2.2: icmp_seq=0 ttl=62 time=1.340 ms - 10.1.2.2 ping statistics 1 packets transmitted, 1 packets received, 0% packet loss 92 This Week: Deploying BGP Multicast VPNs, 2ND Edition round-trip min/avg/max/stddev = 1.340/1.340/1.340/0.000 ms The 0% packet loss figure should be reported for the remaining tests from CE1 (and accordingly from other CEs): user@CE1> ping 10.11.2.2 routing-instance black count 1 user@CE1> ping 10.1.3.2 routing-instance black count 1 user@CE1> ping 10.11.3.2 routing-instance black count 1 user@CE1> ping 10.1.4.2 routing-instance black count 1 user@CE1> ping 10.11.4.2 routing-instance black count 1 user@CE1> ping 10.2.2.2 routing-instance white count 1 user@CE1> ping 10.22.2.2 routing-instance white count 1 user@CE1> ping 10.2.3.2 routing-instance white count 1 user@CE1> ping 10.22.3.2 routing-instance white count 1 user@CE1> ping 10.2.4.2 routing-instance white count 1 user@CE1> ping 10.22.4.2 routing-instance white count 1 Unicast Routes and Routing Protocols at the PEs Each PE has IS-IS and LDP adjacencies with the P and with another PE, according to Figure 2.1 In other words, there are two IS-IS adjacencies, two LDP neighbors, and two LDP sessions at each PE You can check that with the following commands: user@PE1> show isis adjacency user@PE1> show ldp neighbor user@PE1> show ldp session Each PE has one single BGP session with the P router, which acts as a Route Reflector: user@PE1> show bgp summary Groups: 1 Peers: 1 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending bgp.l3vpn.0 12 12 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/ Received/Accepted/Damped 10.101.5.5 65000 70 58 0 1 24:00 Establ bgp.l3vpn.0: 12/12/12/0 black.inet.0: 6/6/6/0 white.inet.0: 6/6/6/0 There are three remote PEs, and each PE advertises both a direct and a static route (PE-CE link and CE-host link) So there should be six different inet-vpn BGP routes imported at each VRF Verify that each PE is advertising two routes for each VRF: user@PE1> show route advertising-protocol bgp 10.101.5.5 black.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.1.1.0/30 Self 100 I * 10.11.1.0/30 Self 100 I white.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 10.2.1.0/30 Self 100 I * 10.22.1.0/30 Self 100 I Display all the routes installed at each VRF (only black is shown here): user@PE1> show route table black black.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) Appendix 93 + = Active Route, – = Last Active, * = Both 10.1.1.0/30 *[Direct/0] 09:21:10 > via ge-0/0/2.1 10.1.1.1/32 *[Local/0] 09:21:10 Local via ge-0/0/2.1 10.1.2.0/30 *[BGP/170] 00:23:57, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 16, Push 301472(top) 10.1.3.0/30 *[BGP/170] 00:23:53, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 17, Push 303312(top) 10.1.4.0/30 *[BGP/170] 00:02:57, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 16, Push 303328(top) 10.11.1.0/30 *[Static/5] 09:21:10 > to 10.1.1.2 via ge-0/0/2.1 10.11.2.0/30 *[BGP/170] 00:23:57, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 16, Push 301472(top) 10.11.3.0/30 *[BGP/170] 00:23:53, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 17, Push 303312(top) 10.11.4.0/30 *[BGP/170] 00:02:57, localpref 100, from 10.101.5.5 AS path: I > via so-0/1/0.0, Push 16, Push 303328(top) TRY THIS What MPLS labels are being pushed? The top label is learned via LDP, and inner label via BGP Execute show route table inet.3, show ldp database, and show route receive-protocol 10.101.5.5 for more details 94 This Week: Deploying BGP Multicast VPNs, 2ND Edition What to Do Next & Where to Go www.juniper.net/dayone The Day One book series is available free download in PDF format here Select titles also feature a Copy and Paste edition for direct placement of Junos configurations (The library is available in eBook format for iPads and iPhones from the Apple iBookstore, or download to Kindles, Androids, Blackberrys, Macs and PCs by visiting the Kindle Store In addition, print copies are available for sale at Amazon or Vervante.com.) www.juniper.net/books Check out the complete Juniper Networks Books library forums.juniper.net/jnet The Juniper-sponsored J-Net Communities forum is dedicated to sharing information, best practices, and questions about Juniper products, technologies, and solutions Register to participate in this free forum www.juniper.net/techpubs/ Juniper Networks technical documentation includes everything you need to understand and configure all aspects of Junos, including BGP MVPN The documentation set is both comprehensive and thoroughly reviewed by Juniper engineering www.juniper.net/training/fasttrack Take courses online, on location, or at one of the partner training centers around the world The Juniper Network Technical Certification Program (JNTCP) allows you to earn certifications by demonstrating competence in configuration and troubleshooting of Juniper products If you want the fast track to earning your certifications in enterprise routing, switching, or security use the available online courses, student guides, and lab guides www.juniper.net/us/en/local/pdf/whitepapers/2000291-en.pdf A white paper on emerging Multicast VPN Applications www.juniper.net/us/en/local/pdf/whitepapers/2000320-en.pdf A white paper on understanding Junos OS BGP Multicast VPNs ... Technologies This Week: Deploying BGP Multicast VPNs, 2ND Edition By Antonio Sánchez Monge Chapter 1: Introducing BGP Multicast VPN Chapter 2: BGP Multicast VPN... This Week: Deploying BGP Multicast VPNs, 2ND Edition Protocol Independent Multicast (PIM) PIMv2 is the industry de facto IPv4 Multicast routing protocol PIM is responsible for building multicast. .. (S, G) multicast traffic allows it to learn the source address (S) Figure 1.4 illustrates the switchover process 12 This Week: Deploying BGP Multicast VPNs, 2ND Edition Multicast Traffic Multicast