About This E-Book

About This E-Book

EPUB is an open, industry-standard format for e-books. However, support for EPUB and its many
features varies across reading devices and applications. Use your device or app settings to customize
the presentation to your liking. Settings that you can customize often include font, font size, single or
double column, landscape or portrait mode, and figures that you can click or tap to enlarge. For
additional information about the settings and features on your reading device or app, visit the device
manufacturer’s Web site.
Many titles include programming code or configuration examples. To optimize the presentation of
these elements, view the e-book in single-column, landscape mode and adjust the font size to the
smallest setting. In addition to presenting code and configurations in the reflowable text format, we
have included images of the code that mimic the presentation found in the print book; therefore, where
the reflowable format may compromise the presentation of the code listing, you will see a “Click here
to view code image” link. Click the link to view the print-fidelity code image. To return to the
previous page viewed, click the Back button on your device or app.
Title Page
IP Multicast, Volume 1
Cisco IP Multicast Networking
Josh Loveless, CCIE No. 16638
Ray Blair, CCIE No. 7050
Arvind Durai, CCIE No. 7016

800 East 96th Street

Indianapolis, Indiana 46240 USA
Copyright Page
IP Multicast, Volume 1
Cisco IP Multicast Networking
Josh Loveless, CCIE No. 16638
Ray Blair, CCIE No. 7050
Arvind Durai, CCIE No. 7016
Copyright© 2017 Cisco Systems, Inc.
Cisco Press logo is a trademark of Cisco Systems, Inc.
Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording, or by any information storage
and retrieval system, without written permission from the publisher, except for the inclusion of brief
quotations in a review.
Printed in the United States of America
First Printing
Library of Congress Control Number: 2016952323
ISBN-13: 978-1-58714-459-2
ISBN-10: 1-58714-459-X
Warning and Disclaimer
This book is designed to provide information about IP multicast networking. Every effort has been
made to make this book as complete and as accurate as possible, but no warranty of fitness is
implied.
The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc.
shall have neither liability nor responsibility to any person or entity with respect to any loss or
damages arising from the information contained in this book or from the use of the discs or programs
that may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of Cisco
Systems, Inc.
Feedback Information
At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each
book is crafted with care and precision, undergoing rigorous development that involves the unique
expertise of members from the professional technical community.
Readers’ feedback is a natural continuation of this process. If you have any comments regarding
how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can
contact us through email at feedback@ciscopress.com . Please make sure to include the book title and
ISBN in your message.
We greatly appreciate your assistance.
Editor-in-Chief: Mark Taub
Business Operation Manager, Cisco Press: Ronald Fligge
Product Line Manager: Brett Bartow
Managing Editor: Sandra Schroeder
Development Editor: Christopher Cleveland
Senior Project Editor: Tonya Simpson
Copy Editor: Christopher Morris
Technical Editors: Nick Garner, Tianji Jiang
Editorial Assistant: Vanessa Evans
Cover Designer: Chuti Prasertsith
Composition: codeMantra
Indexer: Erika Millen
Proofreader: Sasirekha Durairajan
Trademark Acknowledgments
All terms mentioned in this book that are known to be trademarks or service marks have been
appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this
information. Use of a term in this book should not be regarded as affecting the validity of any
trademark or service mark.

Americas Headquarters Cisco Systems. Inc.

San Jose, CA
Asia Pacific Headquarters Cisco Systems (USA) Pte. Ltd.
Singapore
Europe Headquarters Cisco Systems International BV
Amsterdam, The Netherlands
Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are
listed on the Cisco Website at www.cisco.com/go/offices .
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus,
Cisco StadiumVision, Cisco Telepresence, Cisco WebEx, DCE, and Welcome to the Human Network
are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks;
and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP,
CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me
Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort,
the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound,
MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels,
ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to
Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of
Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective
owners. The use of the word partner does not imply a partnership relationship between Cisco and any
other company. (0812R)
About the Authors
About the Authors
Josh Loveless, CCIE No. 16638, is a customer solutions architect for Cisco Systems. He has been
with Cisco for four years, providing architecture and support services for Tier 1 service providers as
well as for many of Cisco’s largest enterprise customers, specializing in large-scale routing and
switching designs. Currently, Josh is helping Cisco’s customers in the defense and intelligence
industries meet the challenges of an ever-changing technology landscape, designing secure automated
networks with advanced capabilities, including IP multicast. Prior to joining Cisco, he spent 15 years
working for large service providers and enterprises as both an engineer and an architect, as well as
providing training and architecture services to some of Cisco’s trusted partners. Josh maintains two
CCIE certifications, Routing and Switching and Service Provider.
Ray Blair, CCIE No. 7050, is a distinguished systems engineer and has been with Cisco Systems
since 1999. He uses his years of experience to align technology solutions with business needs,
insuring customer success. Ray started his career in 1988, designing industrial monitoring and
communication systems. Since that time, he has been involved with server/database administration
and the design, implementation, and management of networks that included networking technologies
from ATM to ZMODEM. He maintains three CCIE certifications in Routing and Switching, Security,
and Service Provider (No. 7050), is also a Certified Information Systems Security Professional
(CISSP), and a Certified Business Architect (No. 00298). Ray is coauthor of two Cisco Press books,
Cisco Secure Firewall Services Module and Tcl Scripting for Cisco IOS . He speaks at many
industry events and is a Cisco Live distinguished speaker.
Arvind Durai, CCIE No. 7016, is a director of solution integration for Cisco Advanced Services.
His primary responsibility in the past 17 years has been in supporting major Cisco customers in the
enterprise sector, including financial, retail, manufacturing, ecommerce, state government, utility
(smart grid networks), and healthcare sectors. Some of his focuses have been on security, multicast,
network virtualization, and data center, and he has authored several white papers and design guides
on various technologies. He has been involved in multicast designs for several enterprise customers
in different verticals. He is also one of the contributors in providing the framework for Advanced
Services Multicast Audit tool that helps customers assess their operational multicast network to
Industry best practices.
Arvind maintains two CCIE certifications: Routing and Switching and Security and also is a
Certified Business Architect. He holds a Bachelor of Science degree in Electronics and
Communication, a Master’s degree in Electrical Engineering (MS), and a Master’s degree in
Business Administration (MBA). He is a coauthor of three Cisco Press books: Cisco Secure Firewall
Services Module , Virtual Routing in the Cloud , and TcL Scripting for Cisco IOS . He has
coauthored IEEE WAN smart grid architecture and presented in many industry forums, such as IEEE
and Cisco Live.
About the Technical Reviewers
About the Technical Reviewers
Nick Garner, CCIE No. 17871, is a solutions integration architect for Cisco Systems. He has been
in Cisco Advanced Services, supporting customers in both transactional and subscription
engagements, for 8 years. In his primary role, he has deployed and supported large-scale data center
designs for prominent clients in the San Francisco Bay Area. His primary technical focus, outside of
data center routing and switching designs, has been security and multicast. Prior to joining Cisco,
Nick worked for a large national financial institution as a network security engineer. Nick maintains
two CCIE certifications, Routing and Switching and Security.
Tianji Jiang, Ph.D., is a dual CCIE (No. 19987, R&S and Data Center) and has more than 20
years of experience in the networking field. For the past 15 years, he has worked at Cisco in various
roles, spanning development, escalation, and advanced service delivery. Currently as a Cisco
networking consultant, he has been a key member of many service provider projects, including
planning, designing, implementing, and deploying large IP networks. Tianji graduated with a
Doctorate degree from Georgia Tech, with his Ph.D. dissertation focusing on investigating multicast
scalability and heterogeneity.
Dedications
Dedications
Josh Loveless: This book is dedicated to all those friends and family that have believed in me,
especially to my family who sacrificed to help me make this book a reality and who continue to
support me in my career every day.
Ray Blair: As with everything in my life, I thank my Lord and Savior for his faithful leading that
has brought me to this place. This book is dedicated to my wife, Sonya, and my children, Sam, Riley,
Sophie, and Regan. You guys mean the world to me!
Arvind Durai: This book is dedicated to my wife Monica, who is my best friend and advisor. I
would also like to thank my son Akhhill for putting up with the long hours I spent working on this
book.
Amma and Appa! thanks for your love, care, and wisdom that is the foundation of everything that I
am today.
Finally, I would like to thank my in-laws, my brother and family, my brother-in-law and family, my
cute nephews Naren, Ariyan, and Ishan, and my adorable nieces Alamelu and Diya.
Above all, thank you, God!
Acknowledgments
Acknowledgments
Josh Loveless: Special thank you to my coauthors, Ray and Arvind! I couldn’t ask for a better
team. The technical editing for this book went above and beyond my expectations. Thanks, Nick and
Tianji. The feedback was fantastic! A special thanks also to the IOS/XE, IOS-XR, and NX-OS
programming and product teams for making multicast a priority and for all the great materials
published for multicast configuration.
Ray Blair: This project was a significant undertaking, and without the partnership of Josh and
Arvind, and the support of those mentioned here and many others, this would not have been an
achievable goal. I am very grateful for all your help and support in completing this book!
Thanks to my wife, Sonya, and my children, Sam, Riley, Sophie, and Regan, for your patience in
the many hours I spent working on this book.
Josh and Arvind, your excellent technical knowledge and dedication to the accuracy of the content
made writing this book a pleasure. I look forward to many more years as your colleague and friend.
Arvind Durai: Thanks to my wife, Monica, for encouraging me to write my fourth book. You
always kept my spirits high. Thank you!!!
Ray, this is my third book with you. We go a long way back, and working with you has always been
a pleasure. Josh, I appreciate your dedication in this project more than you will ever know. Every
success is a result of teamwork; you both have made the experience of writing this book a pleasure.
Thank you!
Thanks to Mark Davis for supporting me in all my endeavors!
Our special thanks to:
We are very grateful to Nick Garner and Tianji Jiang for their valuable input in providing direction
and maintaining the accuracy of the material in this book. Without the talent of these two technical
reviewers, the book would not have been possible.
The Cisco Press team was very helpful in providing excellent feedback and direction, many thanks
to Brett Bartow and Christopher Cleveland.
Command Syntax Conventions
Command Syntax Conventions
The conventions used to present command syntax in this book are the same conventions used in the
IOS Command Reference. The Command Reference describes these conventions as follows:
Boldface indicates commands and keywords that are entered literally as shown. In actual
configuration examples and output (not general command syntax), boldface indicates commands that
are manually input by the user (such as a show command).
Italics indicate arguments for which you supply actual values.
Vertical bars (|) separate alternative, mutually exclusive elements.
Square brackets [ ] indicate optional elements.
Braces { } indicate a required choice.
Braces within brackets [{ }] indicate a required choice within an optional element.
Introduction
Introduction
IP Multicast, Volume I covers basic IP multicast principles and routing techniques specific to
Cisco Systems routers and switches. Included is a pragmatic discussion of common features,
deployment models, and field practices for IP multicast networks. The discussion culminates with
commands and methodologies for implementing and troubleshooting Cisco IP multicast networks.
Who Should Read This Book?
IP Multicast, Volume I is intended for any professional supporting IP multicast networks. This
book primarily targets the following groups, but network managers and administrators will also find
value from the included case studies and feature explanations:
IP network engineers and architects
Network operations technicians
Network consultants
Security professionals
Collaboration specialists and architects
How This Book Is Organized
This book is organized in seven chapters. It starts with an introduction to data communication in IP
networks. Network access, Layer 2, and Layer 3 multicast is explained, along with protocol
independent multicast (PIM). Chapter 5 introduces multicast scoping and covers design
considerations. The final chapters explain IPv6 multicast, and the operation and troubleshooting of IP
multicast networks. The following are the chapters covered in this book:
Chapter 1 , “Introduction to IP Multicast ”: This chapter introduces the reader to the basic
concepts of multicast through the use of graphics and short explanations. It answers the question:
What is multicast and why is it needed? We discuss the basic reasons for using multicast, give some
practical examples of multicast applications, and describe the basics of IP multicasting and how it
differs from unicasts and broadcasts.
Chapter 2 , “Network Access and Layer 2 Multicast ”: This chapter introduces the concepts
of multicast at the access layer, including layered encapsulation, IGMP group management, and the
concept of switching multicast frames. It also discusses Layer 2 switching domains and IPv4 group
address to MAC address mapping.
Chapter 3 , “IP Multicast at Layer 3 ”: This chapter introduces the concepts of multicast at
Layer 3 of the OSI model. It covers the types of multicast hosts, and gives an introduction to the
various modes of PIM.
Chapter 4 , “Protocol Independent Multicast ”: The PIM discussion includes a description of
basic forwarding trees, rendezvous point (RP) mechanics, and ways to propagate RP mapping
information. The chapter concludes with a discussion of the different forwarding modes for multicast
networks, ASM, SSM, and the PIM Bidir.
Chapter 5 , “IP Multicast Design Considerations and Implementation ”: This chapter
discusses the considerations required for a basic multicast network design. It focuses on properly
scoping a multicast enterprise network. It also discusses the concepts of forwarding replication as
well as MFIB and MRIB, which allow the reader to make educated decisions about which
implementation options to choose. The chapter also covers deployment IP multicast best practices
with respect to security and resiliency.
Chapter 6 , “IPv6 Multicast Networks ”: This chapter introduces the concepts of IPv6
multicast. It provides the reader an overview of Layer 2 and 3 multicast for IPv6. It also explains RP
deployment concepts unique to IPv6.
Chapter 7 , “Operating and Troubleshooting IP Multicast Networks ”: This chapter is a
simple guide to operating and troubleshooting basic multicast networks essential for network
administrators managing multicast networks.
Chapter 1. Introduction to IP Multicast
Chapter 1. Introduction to IP Multicast
There are three data communication methods in IP networks: unicast, broadcast, and multicast. To
establish a baseline, it is important to understand the fundamental elements of unicast and broadcast
before we explore the details of multicast communication methods.
Unicast communication at Layer 3 (the Network layer) of the Open Systems Interconnect (OSI)
model is based on the IP address of the destination device. Routers learn about routes by static or
dynamic methods and forward traffic by looking at the destination IP address. Layer 2 (the Data Link
layer) uses another mechanism to establish communication between devices using media access
control (MAC) addresses.
Take a look at Figure 1-1 . The sender is sending a message to Receiver A, and this requires a
combination of both L2 and L3 services. The sender learns the MAC address of the gateway using the
Address Resolution Protocol (ARP) and sends IP traffic destined to any network other than the local
subnet to the gateway/router. The router looks at the destination IP address and forwards the packet to
the next router based on the information in the routing table (Layer 3). The destination router receives
the packet and forwards it to the receiver (Receiver A, in this example). As you can see, the Sender
never learns the MAC address of Receiver A because Receiver A is not on the same subnet.

Figure 1-1 Unicast Packet Forwarding Example

Most nontechnical people are familiar with broadcasting. A broadcast , in this classic sense, is a
signal that is propagated through electromagnetic waves in the air. The signal saturates the broadcast
area, and retrieving the communication is a simple matter of tuning in to a specific frequency. In the
networking world, a broadcast is a message sent to all devices on a subnet or a Layer 2 domain, and
every device has an obligation to check the message to validate whether they are an intended
recipient.
Note
An Ethernet broadcast is very different from an IP broadcast. Remember that IP packets (Layer 3)
are encapsulated inside an Ethernet frame (Layer 2). There are source addresses and destination
addresses at each layer, and each receives different treatment by networking devices. The destination
address of a Layer 3 broadcast in IP is all ones in the host portion of the address. Thus, all hosts
would be 255.255.255.255. At Layer 2, an all-hosts broadcast is ffff.ffff.ffff, and switches must
replicate these packets when forwarding in order to reach all intended recipients, regardless of
physical segment (known as flooding ). If a device was looking for a particular IP host but did not
know the destination MAC address, it could send an IP unicast message encapsulated in an all-hosts
Ethernet broadcast. Every machine on the Ethernet segment receives the packet, but only the intended
IP host processes the packet fully and responds. In fact, this is exactly what an initial ARP request
looks like.
We have traditionally used a router or Layer 3–capable switch to segment broadcast domains and
protect devices from unwanted traffic. This means the router or Layer 3 switch must inspect Ethernet
and IP headers and search for broadcast messages. If a packet is a broadcast packet, the router must
make a forwarding decision on the destination address. If the address is a local broadcast (intended
for only local hosts) the router should drop the packet because this is usually in the format of an all-
hosts broadcast (255.255.255.255). If the address is a directed broadcast (a broadcast intended for a
specific segment or subnet, such as, for example, 10.1.1.255) the router may forward the broadcast
toward the targeted segment, or it may respond if the receiving interface is on the intended segment.
A multicast message is a similar, more efficient version of a broadcast, which is a replicated
packet that is sent to a set of hosts. The primary exception is that with a multicast message, the
intended recipients of the flow could be on any segment instead of on one specific segment. This
process of receiving a single packet, replicating it, and sending copies to additional network
interfaces is the key to understanding how multicast works, from the highest to the lowest level.
Routers and switches must replicate the packet from the source interface and forward toward
receivers. Multicast incorporates the concept of selective learning of data flow by multiple receivers
in Layer 2 and 3 domains. Multicast data distribution methods optimize bandwidth usage and create
an efficient method of data distribution.
What Problem Does Multicast Solve?
The purpose of multicast is to send information to a select group of devices and to avoid
duplication of traffic streams, consequently saving precious network resources such as bandwidth
utilization.
Consider the other two mechanisms to propagate information throughout a network—unicast and
broadcast. Using the example of an Internet radio station transmitting information, unicast requires
that each device on the network interested in listening to the audio stream has a unique session
established. As shown in Figure 1-2 , unicast has one sender and three receivers. A sender is a
device that generates information and advertises it to a group, and a receiver is a device that listens to
the information.
 Figure 1-2 Unicast Using Multiple Streams
Because each stream is being replicated, the sender must replicate the information for each client
and the network connection takes three times the bandwidth. This may not be a big problem for a low-
bandwidth audio session with only three users, but consider scaling to tens of thousands or millions
of sessions. Replicating information for every client creates a significant impact on network
resources.
By using broadcasts, the radio station can minimize the number of sessions the sender has to be
concerned with, which reduces bandwidth from the sender to the network; however, in this case, the
radio station has a different challenge. Referring to Figure 1-3 , the problem of replicating numerous
streams has been eliminated, and the bandwidth challenge has been mitigated, but now every device
receives the radio station whether they are interested in listening to it or not. As the number of radio
stations increases, every device on the network becomes more and more inundated with information it
might not want. The receivers are now obligated to process the radio streams and to decide whether
that information is relevant. Welcome to networking in the 1980s and 1990s, when broadcast storms
were a common occurrence.

Figure 1-3 Broadcast

Multicast to the rescue! We have the best of both worlds with multicast, minimizing the number of
sessions required by the sender and reducing the network load to a single traffic flow. We also obtain
the benefits of unicast by sending the radio station packets only to the devices interested in receiving
them. Referring to Figure 1-4 , with multicast, only a single stream is sent and replicated to the
interested receivers.

Figure 1-4 Multicast

IP multicast messages are transmitted from one-to-many, from many-to-many, and/or from many-to-
one over an IP infrastructure that may span Layer 3 boundaries. The destination nodes (receivers)
send join and leave messages that create an on-demand community of devices interested in receiving
the multicast stream. Multicast optimally uses network resources by requiring the source to send a
single packet stream, even though large numbers of receivers might need to receive the messages. The
replication of messages takes place at the network node(s) or Layer 3 device(s) and diverges the
stream to the receivers. The optimization of the message flow of multicast is leveraged by many
applications. These applications are one of the major driving forces for the adoption of multicast in
the network infrastructure. Some of the more common applications that rely on multicast are as
follows:
Stock exchanges
Computer imaging applications
Music-on-hold services
Sensor updates
Video distribution
Corporate webcasts
Having a good understanding of the nuances of multicast enables you to effectively support those
applications and services that rely on multicast as a transport mechanism. This chapter covers some
of the applications and services that rely on multicast, examines the history of multicast, and delves
into some of the standards.
Multicast Applications and Services
The network infrastructure is in place to support applications and services. These applications and
services allow an entity—a government agency, bank, retail organization, hospital, emergency
services, or any other business or institution—to fulfill its mission or business objective. Establishing
an infrastructure that enables the effective use of these multicast applications and services helps to
ensure the success of that organization.
One-to-Many Multicast Applications
The most common form of multicast applications is one-to-many , as shown in Figure 1-5 .

Figure 1-5 Multicast Using One-to-Many

As the name implies, there is one sender and multiple simultaneous receivers. Typical applications
include video and audio broadcast, but there are many other applications as well, including the
following:
Television
Radio
Distance learning
Presentation sharing and whiteboard applications
Computer imaging software and application updates
Data distribution and caching
Informational updates:
Weather
News
Time—Network Time Protocol (NTP)
Sensors that collect environment information (water levels, temperatures, seismic readings, and
so on).
Many-to-Many Multicast Applications
With many-to-many multicast applications, the senders also act as receivers. This permits all the
devices in the group to simultaneously communicate with one another, as shown in Figure 1-6 .
 Figure 1-6 Multicast Using Many-to-Many
Many-to-many applications include the following:
Audio and video communication
Document sharing and whiteboard applications
Data distribution, caching, and synchronization
Group chat applications
Financial applications
Polling applications
Multiplayer games.
Many-to-One Multicast Applications
Many-to-one applications have many senders but only one or few receivers, as shown in Figure 1-
7 . This is not a common multicast offering, and it has a significant challenge in that the receiver might
not be able to process the information when many devices are sending multicast flows. Scalability is
a significant concern with this model. In some ways, this model is not an improvement over using
unicast streams but instead allows configuration flexibility for the application. In fact, in many cases,
the receiver will respond to senders via a unicast flow. See RFC 3170 for more details on many-to-
one applications.
 Figure 1-7 Multicast Using Many-to-One
Some of the applications for many-to-one include the following:
Data collection
Service discovery
Polling
Multicast applications can consume a tremendous amount of bandwidth, as with high-definition
video, or it can consume very little network bandwidth, as in time updates. All of these applications
rely on the infrastructure for the successful operation of the previously mentioned applications and
services.
Multicast Packet
As mentioned previously, multicast is a communication method for reaching many participants with
a single message flow. In an Ethernet network running Internet Protocol (IP), the active components
that make up the infrastructure, primarily routers and switches, are responsible for replicating the
single packet flow into multiple packets or messages that are efficiently distributed to other devices
interested in receiving those messages.
This warrants a brief review of the Open Systems Interconnect (OSI) model and an explanation of
where multicast is applied to the different layers. The OSI model is comprised of the elements shown
in Table 1-1 .
 Table 1-1 Multicast Applied to the OSI Reference Model
Multicast applications commonly use User Datagram Protocol (UDP) on IP. Consequently, the
Transport layer is used, and this would not be possible without the Network layer running the IP
protocol. The IP layer is also where routers primarily function. The Data Link layer is where Ethernet
switches replicate multicast traffic on a subnet using multicast media access control (MAC)
addresses.
You need to have a solid understanding of the OSI model to comprehend the dynamics of IP
multicast technologies and how each layer interacts with one another.
Note
We refer to a frame as a Layer 2 message in that we are focusing on the source and/or destination
MAC address. A packet is a Layer 3 message that includes a source and a destination IP address.
It is important to understand exactly how routers build a multicast routing information base (MRIB)
and how they use the unicast routing information base (RIB) to ensure loop-free forwarding paths.
Mathematically, a tree is the best way for a routing or switching device to guarantee loop free
topologies. Multicast routers and switches are master tree builders, which will be covered in more
detail throughout this book.
What Is a Source?
When speaking about multicast, there are always two types of hosts, a multicast source and a
multicast receiver. A multicast source can be any device with an IP address in the network. To
become a source, a host only needs to send a message to a multicast group IP address. (See Figure 1-
8 .) The three senders in this diagram are all sending to the same multicast destination address of
239.1.1.1.
 Figure 1-8 Multicast Source
A source does not need to indicate any intention to send to a group before sending a multicast
message. Any IP enabled device, including a router or switch, can send packets toward a multicast
group. When an IP multicast router processes a message destined to a multicast group, a new
multicast forwarding entry is created. This is the Source, Group entry and is called source comma
group , (S, G) . The (S, G) entry for Sender A in Figure 1-8 would be (192.168.0.2, 239.1.1.1).
The (S, G) entry refers to the source IP address and the destination group separated by a comma.
The IP addresses of the senders in Figure 1-8 are the source (S) addresses, whereas the destination IP
address of the group is G. Notice that the three devices are all sending to the same group address.
Could this be a problem? Keep that thought in the back of your mind as you continue reading.
What Is a Receiver?
A receiver is any multicast-enabled device that has expressed interest in a particular multicast
group or a specific (S, G) pair. Unless the multicast is link-local (not passed on through the network
by any router, such as, for example, the “all-routers” IPv4 group of 224.0.0.2), the IP devices must be
configured by the administrator or by an application to subscribe to a specific multicast group. After
it’s subscribed, a multicast receiver listens for packets that arrive with the multicast group destination
address, like group 239.1.1.1 used in Figure 1-8 .
Group subscription is managed by the Internet Group Messaging Protocol (IGMP). When a
receiver subscription for a specific group or set of groups is received or initiated by a router, the
router adds what is called a star comma G, (*, G) entry to the MRIB. The (*, G) entry simply
represents that the router has an interest in the group.
Note
Multicast forwarding information based (MFIB) and multicast routing information base (MRIB)
are terms used to understand the multicast flow in Cisco routers.
The MRIB is responsible for routing information that is generated by multicast protocols. This
information feeds into the MFIB responsible for forwarding multicast packets and collecting statistics
on the multicast flow.
 L3 Multicast Is Built on the TCP/IP Protocol Stack
IP multicast is built on the TCP/IP protocol stack. That means that the protocols necessary to
transport multicast frames and packets are controlled by the Internet Engineering Task Force (IETF).
IETF members develop and manage protocols through the RFC process, which means that IP
multicast protocols are open standards.
Note
Multicast protocol IETF development applies to both IPv4 and IPv6 multicast technologies;
however, as with other IP-based protocols, that does not mean that every manufacturer treats multicast
the same. It also does not mean that every implementation of multicast protocols is perfectly standard-
compliant.
Using the TCP/IP stack also means that IP multicast is subject to the Internet Assigned Numbers
Authority (IANA). IANA controls and coordinates the assignment and use of IP addresses in public
spaces. This includes multicast address assignment.
It’s a Group Thing
A contrast and comparison between L3 unicasts, broadcasts, and multicasts will illustrate the
uniqueness of multicast transmissions. The primary difference between a broadcast and a multicast is
that multicast receivers can connect anywhere on any network segment or subnet, whereas subnets
define broadcast boundaries, called broadcast domains . Routers and switches must therefore have a
way of recognizing which segments and subnets connect interested multicast hosts. Senders and
receivers manage this process through group membership .
A broadcast uses a specific destination IP address in the packet to reach each receiving host.
Routers and switches immediately recognize broadcasts without any additional protocol overhead
because the subnet defines the broadcast boundary. The following packet header breakdowns show
the difference between a unicast IPv4 packet, a broadcast IPv4 packet, and a multicast IPv4 packet.
Figure 1-9 illustrates a basic unicast IP packet.

Figure 1-9 IPv4 Unicast Packet

Forwarding a unicast message is a simple task—follow the route to the IP destination. Broadcasts
are equally simple to forward. Broadcast packets also follow the route to the destination, but they are
replicated on any switch ports that belong to the appropriate logical Ethernet segment (VLAN or
subnet). There are two types of broadcasts, all-hosts broadcasts and directed broadcasts . An all-
hosts broadcast is intended for every IP host on every subnet in which it is forwarded. A directed
broadcast is intended for every IP host only within a given subnet/supernet or VLAN.
Note
Replication is the simple process of making a copy of a packet to forward through the network.
Replication is required anytime a single packet has more than one intended recipient, as, for example,
with broadcasts and multicasts. Replication is a basic function of any active networking device such
as a switch or router.
If the broadcast includes all-hosts, then the local switch simply replicates the broadcast packet for
each interface in the logical segment on which the packet was received. Figure 1-10 depicts an all-
hosts broadcast on a local segment. Routers, by their nature, do not forward all-hosts broadcasts
received on an interface in a given subnet, consequently segmenting the broadcast domain from the
rest of the network.

Figure 1-10 All-Hosts Broadcast Packet (Indicated by 255.255.255.255 as the Destination IPv4
Address and ffff.ffff.ffff as the Destination MAC Address)
If a broadcast is directed, it is sent through the network toward the intended subnet and replicated
by any switch on that subnet, as shown in Figure 1-11 .
 Figure 1-11 Directed Broadcast Packet (Indicated by the 10.2.2.255 Destination IPv4 Address,
or All Hosts on the 10.2.2.0 Subnet)
The difference between a multicast and a broadcast with hosts on a single subnet is subtle. What if
only a few of the hosts on the subnet need to receive the packets? Using a group address to which
hosts can subscribe would ease the burden of sending packets to the select hosts on that segment,
reduce replication overhead, and use the bandwidth only in the LAN where the hosts are located.
Figure 1-12 illustrates just such a scenario.

Figure 1-12 Multicast Forwarding to Hosts on a Single Segment

The major difference between a broadcast and multicast is that subscribed hosts of a multicast flow
may exist on multiple segments. How can routers and switches then forward to only those hosts
without replicating the packet for every segment in a network or on the Internet? Multicast senders
transmit IP packets using a specific destination IP address known as a group address using a specific
multicast MAC address. You may have noticed the L2 destination address is not an address on the
local subnet. This will be discussed further in Chapter 2 , “Network Access and Layer 2 Multicast .”
IPv4 Layer 3 Multicast Addressing Defines Groups
The group address simply identifies a group of nodes interested in a flow. The group address
combined with the source IP address identifies the multicast flow. Host receivers express interest in
the flow by notifying upstream network devices of group membership. This expression of interest is
known as joining the group .
IPv4 and IPv6 group addressing is controlled by a combination of IETF RFCs. The most important
and current IPv4 RFC is 5771, which finalizes assignment of the multicast group address space and
the individual group types within that space. The multicast group block address space is derived from
IPv4 classful address space. Table 1-2 details classful routing addressing assignment.

Table 1-2 IPv4 Classful Addressing

Class D addressing is reserved by RFC 5771 for multicast group assignments. RFC 5771 replaced
or updated several RFCs, including RFC 988, which in 1986 originally proposed 1110 as the high-
order bit reservation for IPv4 multicast group identification. RFC 988 supersedes RFC 966, the
original IP multicast theory RFC. Both RFC 988 and 966 are important to the history of multicast, and
a thorough understanding of the theory in each is a great starting point for anyone wishing to dive
more deeply into the roots of multicast technology and terminology.
IPv4 Multicast Group Address Assignments
RFC 5771 further expands the Class D address for suggested IANA multicast group address
assignment and deployment. Table 1-3 illustrates this assignment.
 Table 1-3 IPv4 Multicast Address Assignment
The following is a brief explanation of each block type, and the proper usage:
Local Network Control block (224.0.0/24): The local control block is used for specific
protocol control traffic. Router interfaces listen to but do not forward local control multicasts; for
example, OSPF “all routers” (224.0.0.5). Assignments in this block are publicly controlled by IANA.
You can find a complete list of Local Network Control address assignments at the IANA website
(www.iana.org ).
Note
Routers listen for local control packets only if the control group feature is enabled on the node. For
example, a router interface would only process RIPv2 control group packets (group 224.0.0.9) if
RIPv2 is enabled on that interface.
Internetwork Control block (224.0.1/24): The Internetwork Control block is for protocol
control traffic that router interfaces may forward through the autonomous system number (ASN) or
through the Internet. Examples include 224.0.1.1 Network Time Protocol (NTP), defined in RFC
4330, and 224.0.1.68 mdhcpdiscover, defined in RFC 2730. Internetwork Control group assignments
are also publicly controlled by IANA.
AD-HOC blocks (I: 224.0.2.0–224.0.255.255, II: 224.3.0.0–224.4.255.255, and
III:233.252.0.0–233.255.255.255): Traditionally assigned to applications that do not fit in either the
Local or Internetwork Control blocks. Router interfaces may forward AD-HOC packets globally.
Most applications using AD-HOC blocks require few group addresses (such as, for example, less
than a /24 space). IANA controls any public AD-HOC Block assignments and future assignments will
come from AD-HOC block III, if they are not more suited to Local Control or Internetwork Control.
Public use of unassigned AD-HOC space is also permitted.
 SDP/SAP block (224.2.0.0/16): The Session Description Protocol/Session Announcement
Protocol (SDP/SAP) block is assigned to applications that receive addresses through the SAP as
described in RFC 2974.
Source-Specific Multicast block (232.0.0.0/8): SSM addressing is defined by RFC 4607. SSM
is a group model of IP Multicast in which multicast traffic is forwarded to receivers from only those
multicast sources for which the receivers have explicitly expressed interest. SSM is mostly used in
one-to-many applications. No official assignment from IANA is required to use the SSM block
because the application is local to the host; however, according to IANA policy, the block is
explicitly reserved for SSM applications and must not be used for any other purpose. SSM will be
discussed further in subsequent sections of this and other chapters.
Note
The 232.0.0.0/8 block was originally assigned by IANA for use by the Versatile Message
Transaction Protocol (VMTP).
GLOP block (233.0.0.0/8): These addresses are statically assigned with a global scope. Each
GLOP static assignment corresponds to a domain with a public 16-bit autonomous system number
(ASN), which is issued by IANA. The ASN is inserted in dotted-decimal into the middle two octets
of the multicast group address (X.Y). An example GLOP assignment for an ASN of X.Y would be
233.X.Y.0/24. Domains using an assigned 32-bit ASN should apply for group assignments from the
AD-HOC III Block. Another alternative is to use IPv6 multicast group addressing. Because the ASN
is public, IANA does not need to assign the actual GLOP groups. The GLOP Block is intended for use
by public content, network, and Internet service providers. IANA considers GLOP addressing to be
experimental, and 233.252–255.0.0 is reserved.
Administratively Scoped block (239.0.0.0/8): Administratively Scoped addresses are intended
for local use within a private domain as described by RFC 2365. These group addresses serve a
similar function as RFC 1918 private IP address block (such as, for example, 10.0.0.0/8 or 172.16-
31.0.0/16 blocks). Network architects can create an address schema using this block that best suits
the needs of the private domain and can further split scoping into specific geographies, applications,
or networks. Further information on best practices for scoping this block can be found in Chapter 5 ,
“IP Multicast Design Considerations and Implementation .”
Important Multicast Groups and Group Considerations
There are many multicast groups, each subdivided from a larger block of multicast group ranges.
Each of the group block ranges has a specific application or scope. The scope of each block ranges
from single segments to large enterprise multicast networks to the global Internet. It is important to
understand the RFC and standards for multicast groups when designing multicast networks. Multicast
group addresses play a very important part in “scoping” the multicast domains. Chapter 5 explains
this concept in more detail.
Note
IANA manages globally scoped address assignments as well as any protocol assignments for
applications. Without control over these addresses, there would be little possibility of using them for
protocol interchange or standards-driven communication.
IPv4 Local Network Control
The Local Network Control block, also known as the Link-Local block, consists of IANA assigned
addresses between 224.0.0.0 and 224.0.0.255. These multicast groups are intended for use within a
single subnet or segment. They are not to be forwarded by routers, and therefore have a time-to-live
(TTL) value of 1. Many well-known applications and communications protocols have reserved
address assignments.
Application developers and network administrators should not use group addresses in this block
for any purpose other than the IANA assigned application. Table 1-4 lists some of the most relevant
assignments from the link-local multicast address, taken directly from the IANA database. The table
lists the reserved multicast addresses, the protocol function assigned, and relevant RFCs.
 Table 1-4 IPv4 Link-Local Multicast Addresses
As the table illustrates, many important network functions rely on link-local multicasting. Routing
protocols, including EIGRP, RIPv2, and OSPF use these protocols to send updates to neighbor
routers. IGMP also uses a link-local multicast address to notify gateway routers of group
subscription. The important point to remember is that the Layer 3 devices will not replicate or
forward these packets. Layer 2 devices will forward link-local multicast frames only on ports within
the same Layer 2 domain (VLAN or subnet).
IPv4 Inter-Network Control
The Inter-Network Control block is similar to the Local Network Control block, with the exception
that multicast applications using this block may require that multicast packets be forwarded beyond
the local segment. The block ranges from 224.0.1.0 to 224.0.1.255. Table 1-5 provides a partial list
of some of the more important Internetwork Control block assignments as made by IANA.
 Table 1-5 Inter-Network Multicast Address Addresses
Many infrastructure protocols use assigned Inter-Network Control block group addresses for
protocol communication. A good example of Inter-Network Control multicast is the Cisco Auto-RP
protocol. Cisco Auto-RP uses multicast groups 224.0.1.39 and 224.0.1.40 to dynamically assign,
advertise, and discover rendezvous points (RPs) in a PIM sparse mode network domain; 224.0.1.39
is used for Cisco Announce; and 224.0.1.40 is used for Cisco Discovery.
Using IP multicast for infrastructure communication simplifies the protocol design process. After a
multicast address is assigned to a particular application or protocol, developers need only send
packets to the assigned address to facilitate protocol intercommunication between many devices.
Several of the existing assignments from the Inter-Network Control block may be for applications or
protocols that will never be deployed on a large scale. Approximately one-third of the block space
remains for future development.
The History of Multicast
Necessity is the mother of invention. Steve Deering was a student of Stanford University in the
early 1980s, working on a distributed processing project. One of the underlying communication
mechanisms allowed one device to send a message to many other devices as a single update. As the
project grew, so did the requirement for compute resources. These resources were distributed
throughout the campus, which required a mechanism to communicate to those devices over a router
(L3) infrastructure. This could have been accomplished using multiple unicast messages, or by
broadcasting the messages across the entire network. Neither of these methods were an acceptable
solution in this case because they were too inefficient. The resolution required a unique single group
address, the ability for the routers to participate in sending the messages, and the capability to have
the hosts join or leave the group at will—hence, the birth of multicast.
The MBone
The multicast backbone (MBone) project was started ten years after Dr. Deering’s invention of
multicast. The routers that comprised the Internet at that time did not have the capability to support
native multicast; consequently, the MBone was a handful of Unix hosts connected over tunnels using
Distance Vector Multicast Routing Protocol (DVMRP), running a daemon called mrouted . The
MBone at that time was driven by higher-education institutions and was used to deliver content such
as the Internet Engineering Task Force (IETF) meetings, concerts, and so on, all with a very limited
scope of viewing.
Native Internet Multicast
Native Internet multicast would allow anyone with an Internet connection to view content. Could
you imagine being able to watch any TV channel, listen to any radio station, participate in distance
learning sessions, all via multicast? Unfortunately, the experiment of the MBone driven by academia
in the 1990s has still not moved to a mainstream service offered by Internet Service Providers (ISPs),
because many service providers do not support the transport of multicast traffic across their network.
The adoption of multicast by ISPs has been slowed by security concerns, the complexity of
implementation, and the capability to easily share multicast routing information.
This has not diminished the need for multicast within private networks. As we reviewed earlier,
there are many applications that benefit from an infrastructure that transports multicast traffic. We can
still take advantage of the transport services of the Internet by tunneling multicast traffic over it, even
if it is not supported natively.
IPv6 Multicast
The rapid growth of the Internet is causing the depletion of IPv4 address space. Consequently, IPv6
is taking hold to provide for the expansion of the Internet and to permit our ability to access any
device on the planet.
IPv4 addresses use 32 bits for a numerical value to distinguish individual devices, whereas IPv6
uses 128 bits. This increase offers tremendous scalability. The implementation of IPv6 has another
interesting characteristic in that it no longer supports network broadcasts. The two methods of
communication with IPv6 are either unicast or multicast. Because multicast was considered during the
creation of the protocol, there are inherent capabilities that improve the operation. Besides the greater
amount of address space, there are other features in IPv6 that make the multicast designs simpler. You
will learn much more about the functionality of IPv6 and multicast in Chapter 6 , “IPv6 Multicast
Networks .”
Multicast Development and Standardization
Just as with many other networking technologies, the effort being made to improve multicast has
continued. There have been many enhancements to address the shortfalls and feature enhancements
that were not foreseen during the creation of the protocol.
Could you imagine if every developer decided to write code based on how they thought it should
work? Fortunately, standardization groups collaborate on how to solve technical challenges and
create documentation on how those solutions are to be addressed to achieve compatibility and
interoperability. There are two major standards bodies that help to drive common implementation
methodologies, the Internet Engineering Task Force (IETF) and the Institute of Electrical and
Electronic Engineers (IEEE).
Note
The charter of the Internet Engineering Task Force (IETF) is to make the Internet work better by
producing high-quality and relevant technical documents that influence the way people design, use,
and manage the Internet. The IETF generates documents such as requests for comment (RFC) and best
current practices (BCP).
The Institute of Electrical and Electronics Engineers (IEEE) is the largest technical professional
society and is an association dedicated to advancing innovation and technological excellence for the
benefit of humanity. Besides developing standards for Ethernet, the IETF develops standards for many
other areas.
Summary
The three data communication methods in IP networks are unicast, broadcast, and multicast. Each
of these methods has advantages and disadvantages depending on the application. Multicast offers an
efficient communication mechanism for sending messages to multiple recipients in separate locations.
It is also capable of supporting many-to-many and many-to-one communication.
Multicast applications commonly use User Datagram Protocol (UDP) on IP. Messages are sent by a
source (called the sender) and will send messages (termed as a stream) even if there is not another
device on the network interested in receiving that information. Receivers, on the other hand, must
subscribe to a particular multicast stream in order to inform the network to forward those messages.
IP addressing for multicast is also unique. There are many public and private addresses that have
been allocated for different applications and services. It is imperative to understand what addresses
you plan to use prior to building out a multicast network.
Multicast was developed in the early 1980s from a research project at Stanford University.
Improvements continue as new applications and services are developed and to address security
concerns.
Chapter 2. Network Access and Layer 2 Multicast
Chapter 2. Network Access and Layer 2 Multicast
Chapter 1 , “Introduction to IP Multicast ,” examined the differences between unicast, broadcast,
and multicast messages. This chapter takes an in-depth look at IP multicast messages at Layer 2 and
how they are transported in a Layer 2 domain. This chapter covers the basic elements of multicast
functionality in Layer 2 domains as well as design considerations for multicast deployments.
Layered Encapsulation
Before reviewing multicast in Layer 2, we must discuss fundamental packet-forwarding concepts to
establish a baseline of the process. Encapsulation is an important component of the OSI model for
data communication and is absolutely essential in IP networks. Encapsulation is the method by which
information is added at each layer of the OSI reference model, used for processing and forwarding
purposes. Think of it like an onion, with many layers. This information is added in the form of
headers and footers. At each layer of the OSI reference model, the data is processed, encapsulated,
and sent to the next layer. Take a look at Figure 2-1 to understand how this works.

Figure 2-1 OSI Model and Data Encapsulation

Data from the application, presentation, and session layers (Layers 1, 2, and 3) is encapsulated at
Layer 4 with transport protocol information. This information is encapsulated in TCP and/or UDP
with specific port numbers. For example, TCP port 80 is typically web traffic. This allows an
operating system to forward data to an appropriate application or subroutine. Layer 3 adds logical
forwarding details (source and destination IP addresses) so that networking devices can determine the
best path toward a destination. Finally, Layer 2 adds hardware forwarding information (source and
destination MAC addresses). This allows data to be passed physically to the appropriate machine or
the next hop in a network. A data transmission at Layer 4 is called a segment , a packet at Layer 3,
and a frame at Layer 2.
At each step through a network, routers and switches use these encapsulation headers and footers to
make decisions about how to treat data transmissions. The diagrams in Chapter 1 show much of this
processing in action. In that chapter, you learned the uniqueness of IP multicast packets compared to
unicast and broadcast packets. From a Layer 2 perspective, this is only part of the story.
To better explain what happens to a packet traversing the network, we will walk you through the
Layer 2 and Layer 3 transmission process. Figure 2-2 illustrates the first step in this process. Before
the sender has the ability to encapsulate any data, it must first understand where the destination is
located. The sender performs a simple check to verify if the receiving device is on the same subnet.
This is accomplished by checking the destination IP address against the local subnet. In this example,
the receiver is not on the same subnet. The sender must use the configured route to the destination. In
most cases, this is the default-gateway.

Figure 2-2 Layer 2 and Layer 3 Transport Process on the Local Segment
Before the sender can communicate with the default gateway, it must know the media access
control (MAC) address of that device. Because the destination is on a different segment, the sender
will need to discover the MAC address of the default gateway (IP address 10.1.1.1) using an Address
Resolution Protocol (ARP) request. The default gateway responds to the ARP request with its MAC
address. Finally, the sender has enough information to encapsulate the data with the destination IP
address of Host A and the MAC addresses of the default gateway, as shown in Figure 2-2 .
 The default gateway or router has Layer 3 IP routing information that determines where Host A is
physically connected. This information determines the appropriate outgoing interface to which the
message should be sent. The router should already know the MAC address of the neighbor router if
there is an established routing protocol adjacency. If not, the same ARP request process is conducted.
With this information, the router can now forward the message. Understand that both Layer 2
addresses (SA and DA) change at each logical hop in the network, but the Layer 3 addresses never
change and are used to perform route lookups.
When the packet is forwarded to the final router, that router must do a lookup and determine the
MAC address of the destination IP. This problem exists in part because of the historical implications
of Ethernet. Ethernet is a physical medium that is attached to a logical bus network. In a traditional
bus network, many devices can be connected to a single wire. If the gateway router does not have an
entry from a previous communication, it will send out an ARP request and finally encapsulate with the
destination MAC address of the host, as shown in Figure 2-3 .

Figure 2-3 Layer 2 and Layer 3 Transport Process on the Destination Router
After the final router properly encapsulates the message, it is the responsibility of the switch to
send the packet to the appropriate host, and only to that host. This is one of the primary functions of a
traditional Layer 2 switch—to discover the location of devices connected to it. It does this by
cataloging the source MAC addresses in frames received from connected devices. In this way, the
switch builds a table of all known MAC addresses and keeps Ethernet networks efficient by making
intelligent Layer 2 forwarding decisions.
This process is easy to understand for the unicast packet shown. Items to consider while you read
this chapter include the following:
What happens if the packet is a multicast packet and many hosts connected to a switch are
subscribed to the destination multicast group?
 Can a switch still make efficient forwarding decisions if there are multiple ports that require a
copy of the packet (meaning there are multiple endpoints on multiple segments that need a copy of the
frame)?
If the MAC address in a frame is not the physical address of the host, will it process the packet,
assuming it is not the intended recipient?
How do you identify multicast groups at Layer 2?
MAC Address Mapping
A traditional Ethernet switch (Layer 2 device) works with Ethernet frames, and a traditional router
(Layer 3 device) looks at packets to make decisions on how messages will be handled. As discussed
in Chapter 1 , when a device sends a broadcast frame, the destination address is all ones, and a
unicast message is the destination MAC address. What happens when it is a multicast message? To
optimize network resources, an Ethernet switch also needs to understand multicast. This is where the
magic happens. The sending device must convert the destination IP multicast address into a special
MAC address as follows:
The high-order 25 bits is the official reserved multicast MAC address range from
0100.5E00.0000 to 0100.5E7F.FFFF (request for Comment 1112). These bits are part of the
organizational unit identifiers (OUI).
The lower-order 23 bits of the destination IP multicast address are mapped to the lower-order 23
bits of the MAC address.
The high-order 4 bits for the destination IP multicast address are set to 1110 binary (0b1110).
This represents the Class D address range from 224.0.0.0 (0b11100000) to 239.255.255.255
(0b11101111).
Of the 48 bits used to represent the multicast MAC address, the high-order 25 bits are reserved
as part of the OUI, and the last 23 bits of the multicast IP address are used as the low-order bits, as
shown in Figure 2-4 .
 Figure 2-4 Layer 2 Multicast Address Format
A switch can use this calculated multicast MAC address to distinguish a frame as a multicast and
make efficient forwarding decisions. End hosts can listen for frames with a specific multicast MAC,
allowing them to process only those multicast streams to which they have subscribed. There’s a small
wrinkle in this process, however.
Did you notice a slight challenge with the number of IP addresses and MAC addresses? Five bits
of the IP address are overwritten by the OUI MAC address. This causes a 32-to-1 IP multicast
address-to-multicast MAC address ambiguity (25 = 32).
This means that a host subscribing to a multicast stream could potentially receive multiple
multicast streams that it did not subscribe to, and the host will have to discard the unwanted
information. A host subscribing to the multicast stream of 224.64.7.7 would map to MAC address of
0x0100.5E40.0707, and so would 225.64.7.7 and 224.192.7.7. It all boils down to 1s and 0s. Figure
2-5 shows the ambiguity. The “X” in the binary row represents the bits that are overwritten and
shows how 32 multicast IP addresses map to a single multicast MAC address.
 Figure 2-5 Layer 2 Multicast MAC Address Overlap
Switching Multicast Frames
Layer 2 switches send frames to a physical or logical interface based on the destination MAC
address. Multicast MAC addresses are a different animal than unicast MAC addresses, because a
unicast MAC address should be unique and have only a single destination interface. Multicast MAC
frames may have several destination interfaces, depending upon which devices have requested
content from the associated IP multicast stream.
Before the Layer 2 switch can forward multicast frames, it must know the destination interfaces on
which those messages should be sent. The list of destination interfaces includes only those interfaces
connected to a device subscribed to the specific multicast flow. The destination can be added as
static entries that bind a port to a multicast group, or the switch can use a dynamic way of learning
and updating the ports that need to receive the flow.
There are several ways in which a Layer 2 switch can dynamically learn where the destinations are
located. The switch may use Cisco Group Management Protocol (CGMP) or Internet Group
Management Protocol (IGMP) snooping for IPv4 multicast. These methods will be discussed later in
this chapter.
If a Layer 2 switch does not have a mechanism to learn about where to send multicast messages, it
treats all multicast frames as broadcast, which is to say it floods the packet on every port or VLAN
port! As you can imagine, this is a very bad thing. Many networks have melted down due to large
multicast streams. For example, when sending computer operating system image files, a tremendous
amount of data is sent to every device in the broadcast domain, every computer, router, printer, and so
on. The unfortunate side effect of these messages is that network performance may be affected in
locations on the network that do not need the multicast stream. How could this happen if these are
broadcast messages and will not go beyond the local network? These messages will not go beyond
any local Layer 3 devices, but local Layer 3 devices must process each one of the broadcast
messages. While the Layer 3 device is inundated processing these messages, it may not have the
available cycles to process other more important messages, such as routing updates or spanning-tree
messages. As you can imagine, or may have already experienced, this can impact or “melt-down” the
entire network.
Group Subscription
You have seen that in order for IP multicast forwarding to work on the local segment and beyond,
switches and gateway routers need to be aware of multicast hosts interested in a specific group and
where those hosts are located. Without this information, the only forwarding option is to flood
multicast datagrams throughout the entire network domain. This would destroy the efficiency gains of
using IP multicast.
Host group membership is a dynamic process. When a host joins a multicast group, there is no
requirement to continue forwarding group packets to the segment indefinitely, nor is group
membership indefinite. The only way to manage alerting the network to a multicast host location is to
have multicast host group members advertise interest or membership to the network. Figure 2-6
depicts a high-level example of this requirement, known as a join .

Figure 2-6 Host Joins a Multicast Group

A Layer 3 gateway provides access to the larger network for hosts on a given subnet. The gateway
is the network demarcation between Layers 2 and 3 and is the most appropriate device to manage host
group membership for the larger network. Hosts forward group management information, like joins, to
the network. The gateway receives these management messages and adds host segment interfaces to
the local multicast table (multicast forwarding information base [FIB]). After the FIB is updated, the
gateway router communicates group interest using protocol independent multicast (PIM) to the larger
network domain.
It is important to note that without multicast-aware Layer 2 protocols, all hosts on a given Layer 2
segment will receive multicast packets for any groups joined by a host on that segment. For this
reason, it is also logical that hosts and routers have the capability to dynamically leave a group or to
prune a group from a particular segment. Figure 2-7 describes a high-level example of this process in
action, known as a leave .
 Figure 2-7 Host Leaves a Multicast Group
Administrators can configure the gateway router to statically process joins for specific groups
using router interfaces. This alleviates the need to have a dynamic join/leave process; however,
having a dynamic process simplifies the operational aspects for the administrator. In the next section,
we show you the dynamic process needed to get this intelligence to the Layer 2 networks.
IGMP on the Gateway Router
Internet Group Management Protocol, or IGMP, is the protocol used to manage group subscription
for IPv4 multicast. On the gateway router, called the querier , IGMP is used to track multicast group
subscriptions on each segment. The router sends query messages to discover the hosts that are
members of a group. The hosts send membership report messages to inform the router that they are
interested in receiving or leaving a particular multicast stream, and they also send report messages in
response to a router query message.
Note
When protocol independent multicast (PIM) is enabled on an interface of the router, IGMP (version
2) is also enabled.
IGMP Versions
The selection of which IGMP version(s) to run on your network is dependent on the operating
systems and behavior of the multicast application(s) in use. Generally speaking, the capability of the
operating system determines the IGMP version(s) you are running on your network. There are three
versions of IGMP, version 1, 2, and 3. Each of these has unique characteristics. As of this writing, the
default IGMP version enabled on most Cisco devices is version 2.
IGMPv1
The original specification for IGMP was documented in RFC 988 back in 1986. That RFC, along
with RFC 1054, was made obsolete by RFC 1112, which is known as IGMPv1 today. IGMPv1 offers
a basic query-and-response mechanism to determine which multicast streams should be sent to a
particular network segment.
IGMPv1 works largely like the explanation given in Figure 2-7 , with two major exceptions, a
primary issue with using version one. IGMPv1 has no mechanism for a host to signal that it wants to
leave a group. When a host using IGMPv1 leaves a group, the router will continue to send the
multicast stream until the group times out. As you can imagine, this can create a large amount of
multicast traffic on a subnet if a host joins groups very quickly. This will occur if the host is “channel-
surfing” using IPTV, for example.
In order to determine the membership of a group, the querier (router) sends a message to every host
on the subnet. The functionality of the querier is to maintain a list of hosts in the subnet interested in
multicast flows. Yes, even those that were never interested in receiving any multicast streams. This is
accomplished by sending the query to the “all-hosts” multicast address of 224.0.0.1. When a single
host responds to the query, all others suppress sending a report message.
IGMPv1 also does not have the capability of electing a querier. If there are multiple queriers
(routers) on the subnet, a designated router (DR) is elected using PIM to avoid sending duplicate
multicast packets. The elected querier is the router with the highest IP address. IGMPv1 is rarely used
in modern networks and the default for Cisco devices has been set to v2 because of these limitations.
IGMPv2
As with every invention, we make improvements as we find shortcomings. IGMPv2, as defined in
RFC 2236, made improvements over IGMPv1. One of the most significant changes was the addition
of the leave process. A host using IGMPv2 can send a leave-group message to the querier indicating
that it is no longer interested in receiving a particular multicast stream. This eliminates a significant
amount of unneeded multicast traffic by not having to wait for the group to timeout; the trade-off is that
routers need to track membership to efficiently prune when required.
IGMPv2 added the capability of group-queries. This feature allows the querier to send a message
to the host(s) belonging to a specific multicast group. Every host on the subnet is no longer subjected
to receiving a multicast message.
The querier election process offers the capability to determine the querier without having to use
PIM. In addition, the querier and the DR function are decoupled. This process requires that each
device send a general query message to all hosts 224.0.0.1. If there are multiple routers on a subnet,
the DR is the device with the highest IP address and the querier is the device with the lowest IP
address.
IGMPv2 also added the Maximum Response Time field, which is used to tune the query-response
process to optimize leave latency.
Food for thought: Is a multicast message sent to all-host 224.0.0.1 a broadcast?
Figure 2-8 shows the format for IGMPv1 and IGMPv2 messages.
 Figure 2-8 IGMPv1 and IGMPv2 Message Format
IGMP message types for IGMPv1 and IGMPv2 are as follows:
0x11—Membership query
General query message used to determine group membership of any group
Group-specific query used to verify if any hosts are part of a specific group
0x12—IGMPv1 membership report
0x16—IGMPv2 membership report
0x17—Leave-group message
The maximum response time (MRT) is calculated in one-tenth of a second increments and is used
only with membership query messages. This parameter allows routers to manage the time between the
moment the last host leaves a group and the moment the routing protocol is notified. When a host
receives an IGMP query packet, it kicks off a timer that begins with a random value that is less than
the MRT. If no other host responds with a membership report before this random timer expires, the
host will then reply with a report. This decreases the number of total IGMP reports needed to
maintain the group state as well as preserves local bandwidth, because the host suppresses its own
reports unless absolutely necessary. IGMPv1 does not use MRT; instead, it has a timer that is always
set to 10 seconds. Of course, this means the MRT cannot be less than the query-interval , making the
maximum configurable MRT 25 seconds (1 byte MRT field; 1/10s*255 = 25 seconds).
The checksum is a value calculated using information within the message used to detect errors.
Example 2-1 shows a packet capture of an IGMPv2 membership query. Items of interest include the
source and destination MAC address. The source of this request is the router (192.168.12.1) and the
destination is the multicast MAC address for 224.0.0.1, which includes all devices on the subnet.
Referring to the packet capture in Example 2-1 , you see the IGMP type is 0x11, the maximum
response time is 0x64 (hex for 10 seconds, the default for IGMPv2), the checksum, and the group
address of 0.0.0.0, which indicates that it is a general query message. Also, pay particular attention to
the time to live (TTL) field. This message has the TTL set to 1, which means that it will not be sent to
multiple subnets. If you are troubleshooting multicast problems, you should always make sure the
multicast sender has a TTL value greater than or equal to the diameter of your network.
Example 2-1 IGMPv2 Membership Query Packet Capture
Click here to view code image
 Ethernet Packet: 60 bytes
Dest Addr: 0100.5E00.0001, Source Addr: 0022.5561.2501
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x6, TOS: 0xC0 (Prec=Internet Contrl)
Length: 32, ID: 0x03E6, Flags-Offset: 0x0000
TTL: 1, Protocol: 2 (IGMP), Checksum: 0x7387 (OK)
Source: 192.168.12.1, Dest: 224.0.0.1
Options: Length = 4
Router Alert Option: 94 0000
IGMP VersionType: 0x11, Max Resp: 0x64, Checksum: 0xEE9B (OK)
Version 2 Membership Query
Group Address: 0.0.0.0
Remember that IGMP is a LAN-based protocol, used to manage hosts. Managing hosts is often
considered a chatty process. Several configurable timers, including the MRT, within the IGMP
implementation can be adjusted to modify protocol message timing and processing. Look at the IGMP
interface configuration timers that are listed in the show ip igmp interface x/x command output in
Example 2-2 .
Example 2-2 show ip igmp interface Command Output
Click here to view code image
Router#show ip igmp interface e1/0
Loopback0 is up, line protocol is up
Internet address is 192.168.2.2/32
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP configured query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP configured querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 3 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.2.2 (this system)
IGMP querying router is 192.168.2.2 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1) 224.0.1.39(1) 239.1.1.1(1)
The respective timers in this output are all using implementation default values. In generic
multicast deployments, these timers are not tweaked and are kept “default.” Administrators may
tweak them based on specific application requirements (not commonly seen). It is beneficial to
understand the functionality of these timers:
ip igmp query-interval [interval in secs ]: Hosts on a segment will send a report of their group
membership in response to queries received from the IGMP querier. The query interval defines the
amount of time the router will store the IGMP state if it does not receive a report for the particular
group. This hold period is three times the query interval time.
ip igmp query-max-response-time [time-in-seconds ]: When a host receives a query from the
IGMP querier, it starts the countdown of the maximum response time before sending a report to the
router. This feature helps reduce the chatter between hosts and the first hop router. The max-response
time cannot be less than the query interval value.
ip igmp query-timeout [timeout ]: This timer is used for the querier election process described
earlier, especially when multiple routers are in the LAN segment. A router that loses the election will
assume quierier malfunction based on the expiry of this timer. When the timer is expired, the router
restarts the querier election process.
ip igmp last-member-query-count [number ]: This timer tracks the time the router must wait
after the receipt of the leave message before removing the group state from local state tables. The
timer is overwritten if a router is configured with the command ip igmp immediate-leave group-list [
list ] . With the ip igmp immediate-leave group command, the router treats these groups as having a
single host member. After the reception of a leave message, the router immediately removes the
multicast group.
IGMPv3
The addition of IGMPv3 (RFCs 3376 and 4604) brought with it signification changes over
IGMPv1 and v2. Although there are vast improvements, backward compatibility between all three
versions still exists. To understand why, examine Figure 2-9 , which shows the IGMPv3 header
format. New header elements of importance include a Number of Sources field, a Source Address(es)
field, and a change from a Max Response Time field to a Max Response Code field.
 Figure 2-9 IGMPv3 Message Format
As the header shows, the most signification addition to IGMPv3 is the capability to support
specific source filtering. Why is this a big deal? With IGMPv1 and v2, you could not specify the host
from which you wanted to receive a multicast stream; consequently, multiple sources could be
sending to the same multicast IP address and port number, and the host would now have a conflict
with which stream to receive. Source filtering allows the host to signal membership with either an
include or an exclude group list. This way, the host can specify which device(s) it is interested in
receiving a stream from, or it can indicate which devices that it is not interested in receiving a stream
from. This adds an additional security component that can be tapped at the application level. IGMPv3
is used at Layer 2 for source-specific multicast (SSM). SSM is covered in Chapter 3 .
In addition to this change, the MRT was updated once again in IGMPv3; in fact, it was changed in
RFC 3376 to a maximum response code (MRC). Similar to the MRT field in IGMPv2, the max
response code field indicates the maximum time allowed before a report for a group must be
received. The maximum response code (MRC) can still incorporate the MRT, which is represented in
units of one-tenth of a second. There are 8 bits in the MRC field, and the value of those bits indicates
how the MRC is to be read. If the MRC is less than 128, the Max Response Time is equal to the Max
Response Code value. If the MRC is greater than or equal to 128, the MRC has a floating point value
to reflect much longer periods of time. This makes the total maximum timer configurable up to 55
minutes.
The response time was modified in IGMPv3 to better accommodate different types of network
connectivity. Using a smaller timer allows the network administrator to more accurately tune the
leave latency of hosts. Using a larger timer can accommodate network types where the burstiness of
group management traffic is less desirable, e.g. low bandwidth wireless networks.
Example 2-3 shows a packet capture of a membership report from an IGMPv3 host with the IP
address of 192.168.7.14 with a group membership request to receive a multicast stream from
224.64.7.7 from the source of 192.168.8.10.
Example 2-3 IGMPv3 Membership Report Packet Capture
Click here to view code image
Ethernet II, Src: (80:ee:73:07:7b:61), Dst: (01:00:5e:00:00:16)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.7.14, Dst: 224.0.0.22
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
Total Length: 52
Identification: 0x0000 (0)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 1
Protocol: IGMP (2)
Header checksum: 0x3c37 [validation disabled]
Source: 192.168.7.14
Destination: 224.0.0.22
Options: (4 bytes), Router Alert
Internet Group Management Protocol
[IGMP Version: 3]
Type: Membership Report (0x22)
Header checksum: 0x4a06 [correct]
Num Group Records: 2
Group Record : 224.64.7.7 Mode Is Include
Record Type: Mode Is Include (1)
Aux Data Len: 0
Num Src: 1
Multicast Address: 224.64.7.7
Source Address: 192.168.8.10
Group Record : 224.0.0.251 Mode Is Exclude
Record Type: Mode Is Exclude (2)
Aux Data Len: 0
Num Src: 0
Multicast Address: 224.0.0.251
Notice the destination IP address of the IPv4 packet; it is being sent to 224.0.0.22. This is the IP
address to which all hosts send their membership report.
Configuring IGMP on a Router
A router by default is not configured to support multicast traffic. There are a few basic
configuration tasks that need to be performed on Cisco IOS routers in order to enable multicast on the
network.
Step 1. Enable multicast routing on the router in global configuration mode.
ip multicast-routing
Step 2. Configure PIM routing on the associated interface(s) in the interface configuration
mode. Take into consideration that multicast traffic may traverse many different paths and it is always
a good idea to enable it on every interface that may need to participate. This might save you some
troubleshooting time in the future. When you configure an interface for PIM, it is automatically
configured to use IGMPv2 on most current operating systems.
ip pim sparse-mode
On Cisco switches, IGMP version 2 is enabled by default.
Step 3. If necessary, change the IGMP version supported on an interface.
ip igmp version [1,2,3]
Mixed Groups: Interoperability Between IGMPv1, v2, and v3
It all boils down to the least common denominator. When there is a mix of hosts on a subnet, the
only method for them to communicate is with the lowest IGMP version number used by a host. This is
due to the fact that higher versions understand lower versions for backward compatibility.
The other situation you may encounter is having a mix of clients and several routers on a subnet.
There is no mechanism for routers configured with a lower IGMP version to detect a router running a
higher version IGMP. This requires manual intervention, and someone must configure the routers to
use the same version.
Layer 2 Group Management
As mentioned earlier, Layer 2 devices treat multicast messages as broadcasts when no group
management mechanism is present. This not only causes an increase of traffic on a particular subnet,
but these messages are sent to every device within that subnet (flooding). These devices may treat the
processing of multicast messages differently, depending on the behavior of the operating system and
associated hardware. Multicast messages may be processed in hardware, software, or the
combination of both. Consequently, multicast messages, or too many multicast messages, may have an
adverse effect on a device. It is better to handle multicast messages in the network and only send
messages to the devices that are interested in receiving them.
Two protocols were created to help manage this behavior on LAN segments, Cisco Group
Management Protocol (CGMP) and Router-port Group Management Protocol (RGMP). While both of
these protocols still exist in networks today, they are generally not used in favor of IGMP snooping,
which is discussed in the next section. For this reason, we only provide a brief introduction to these
protocols.
Cisco Group Management Protocol
In order to address the Layer 2 challenges with multicast as a broadcast message, Cisco first
developed a proprietary solution called CGMP. At the time of development, the capabilities of Layer
2 switches did not offer the Layer 3 inspection or snooping of messages as they do today. CGMP was
used between the connected router and switch. The router would send IGMP information to the switch
using CGMP, regarding which clients have registered. The receiving switch could then determine
which interfaces to send the outgoing multicast messages.
CGMP behaves in the following manner: When a host is interested in receiving a stream from a
particular Group Destination Address (GDA), it sends an IGMP report message. This messages is
received by the router and the router in turn sends a CGMP Subnetwork Access Protocol (SNAP)
frame to the destination MAC address of 0x0100.0CDD.DDD with the following information:
Version: 1 or 2
Message field: Join or Leave
Count: Number of address pairs
MAC address of the IGMP client
Group multicast address/Group destination address (GDA)
Unicast source address (USA): MAC address of the host sending the join message
The attached switch, configured to support CGMP, receives the frame from the router. The switch
looks at the USA and performs a lookup in the content addressable memory (CAM) table to determine
the interface of the requesting host. Now that the interface of the requesting host has been determined,
the switch places a static entry for the GDA and links the host address in the CAM table if this is the
first request for the GDA. If there was already an entry for the GDA, the switch just adds the USA to
the GDA table.
Note
Due to conflicts with other protocols such as HSRPv1, CGMP may have certain features disabled.
Always check current configuration guides before enabling CGMP. Using IGMP snooping is an easy
way to avoid such conflicts.
The CGMP Leave Process
The leave process is dependent on the IGMP version of the host. IGMPv1 does not provide a
mechanism to inform the network when it no longer wants to participate in receiving the stream. When
an IGMPv1 host leaves, the only way the network realizes that the host is no longer participating in
the multicast stream is through an IGMP query message. You can imagine that having a host join a
stream, then join another stream, and so on, can cause a significant impact on the amount of traffic on
the network. Consider someone watching IPTV and quickly changing channels. To address this
problem, the router periodically sends IGMP query messages to determine if devices are still
interested in receiving the stream. If a router does not receive a response after sending three IGMP
query messages, it informs the switch via CGMP, which then removes the entries for the GDA.
IGMPv2 added the functionality of a leave message ; this provides the ability for a host to
gracefully leave a session that it is no longer interested in receiving. When a host sends an IGMP
leave message, the router sends a query message and starts a query-response message timer. This
process is done to determine if there are hosts on that specific network that are still interested in
receiving the multicast stream. If the router does not receive a response, it will send a CGMP
message to the switching informing it to remove the entries for the GDA.
Router-Port Group Management Protocol
Along the same lines as CGMP, another protocol, RGMP, was developed to address the multicast
communication of routers over a switched network. When several routers are connected to the same
Layer 2 switched network, multicast messages are forwarded to all protocol independent multicast
(PIM) routers, even those that are not interested in receiving the multicast streams.
RGMP is configured on the switch in conjunction with IGMP snooping (IGMP snooping is
discussed at length in the next section of this chapter). The routers that are connected to the switch are
configured with PIM sparse-mode and RGMP. A router configured with RGMP sends a RGMP hello
messaged to the attached switch. The switch creates an entry indicating the receiving interface is a
RGMP router and will not forward multicast traffic to that interface unless it receives a join message
from the router. A router interested in receiving a specific multicast stream sends a RGMP join
message to the switch with the GDA. The switch in turn creates an entry for the GDA and links the
router interface in the CAM table.
We have covered two of the four RGMP message types, “hello” and “join.” The other messages are
“bye” and “leave.” The “bye” RGMP message tells the switch to place the interface in a normal
forwarding state. Finally, the “leave” message is sent from the router when it no longer is interested
in receiving a specific multicast stream.
Snooping
According to the Merriam-Webster dictionary, snooping is “to look or pry especially in a sneaking
or meddlesome manner.” When we use this term referring to multicast, it means the same thing, with
the exception of the meddlesome manner. When a device monitors the conversation or messages sent
between devices on the network, we can gain a great deal of information which can be used in turn to
tune network behavior to be much more efficient. Over the last several years, Cisco has made great
improvements in the intelligence of the components that make up a switch. Switches can now perform
Layer 3 services, capture analytics, rewrite information, and so on, all at line rate. This increased
intelligence has now provided the capability of a Layer 2 switch to look at more than just the
destination MAC address; it offers the capability to look deep into the message and make decisions
based on Open Systems Interconnect (OSI) Layer 2 to L7 information.
IGMP Snooping
IGMP snooping is one of those features that does exactly what it says. A network component,
generally a Layer 2 switch, monitors frames from devices, and, in this case, it listens specifically for
IGMP messages. During the snooping process, the switch listens for IGMP messages from both
routers and hosts. After discovering a device and determining which GDA that particular device is
interested in, the switch creates an entry in the CAM table that maps the GDA to the interface.
Switches learn about routers using several mechanisms:
IGMP query messages
PIMv1 and/or PIMv2 hellos
Examine Figure 2-10 because it will be used to explain IGMP snooping.
 Figure 2-10 IGMP Snooping
Example 2-4 shows a packet capture of an IGMP query report generated from a router.
Example 2-4 IGMP Query Packet Capture
Click here to view code image
Ethernet Packet: 60 bytes
Dest Addr: 0100.5E00.0001, Source Addr: 0C85.2545.9541
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x6, TOS: 0xC0 (Prec=Internet Contrl)
Length: 32, ID: 0x1FC5, Flags-Offset: 0x0000
TTL: 1, Protocol: 2 (IGMP), Checksum: 0x57A8 (OK)
Source: 192.168.12.1, Dest: 224.0.0.1
Options: Length = 4
Router Alert Option: 94 0000
IGMP VersionType: 0x11, Max Resp: 0x64, Checksum: 0xEE9B (OK)
Version 2 Membership Query
Group Address: 0.0.0.0
When the switch determines there is a router attached, it places an entry in the IGMP snooping
table that specifies the interface, as Example 2-5 demonstrates.
Example 2-5 IGMP Snooping Table
Click here to view code image
Switch#show ip igmp snooping mrouter
Vlan ports
---- -----
12 Gi0/12(dynamic)
In this case, the switch has learned that a router is attached to interface g0/12. This interface is
known as the mrouter port or multicast router port . The mrouter port is essentially a port that the
switch has discerned is connected to a multicast enabled router that can process IGMP and PIM
messages on behalf of connected hosts. An IGMP-enabled VLAN or segment should always have an
mrouter port associated with it. We can also see the effect using the debug ip igmp snooping router
command, which gives us greater insight into the process, as Example 2-6 demonstrates.
Example 2-6 debug ip igmp snooping router Output
Click here to view code image
Switch#debug ip igmp snooping router
router debugging is on
01:49:07: IGMPSN: router: Received non igmp pak on Vlan 12, port Gi0/12
01:49:07: IGMPSN: router: PIMV2 Hello packet received in 12
01:49:07: IGMPSN: router: Is not a router port on Vlan 12, port Gi0/12
01:49:07: IGMPSN: router: Created router port on Vlan 12, port Gi0/12
01:49:07: IGMPSN: router: Learning port: Gi0/12 as rport on Vlan 12
As you see from the output in Example 2-6 , the switch received a PIMv2 hello packet from
interface Gi0/12 and changed the state of the port to a router port.
When a host connected to the switch wants to join a multicast stream, it sends an IGMP
membership report. In Example 2-7 , the host connected to port Gi0/2 is interested in receiving data
from 224.64.7.7. Using the debug ip igmp snooping group command, we can monitor the activity.
Example 2-7 debug ip igmp snooping group Output
Click here to view code image
Switch#debug ip igmp snooping group
router debugging is on
01:58:47: IGMPSN: Received IGMPv2 Report for group 224.64.7.7 received on Vlan 12,
port Gi0/2
01:58:47: IGMPSN: group: Adding client ip 192.168.12.20, port_id Gi0/2, on vlan 12
From the output in Example 2-7 , we can ascertain that the host connected to Gi0/2 is attempting to
connect to the multicast group 224.64.7.7.
Using the show ip igmp snooping groups command, we can also see the entry in the switch, as
demonstrated in Example 2-8 .
Example 2-8 show ip igmp snooping groups Output
Click here to view code image
Switch#show ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
12 224.0.1.40 igmp v2 Gi0/12
12 224.64.7.7 igmp v2 Gi0/2, Gi0/12
 The output in Example 2-8 specifies the VLAN, multicast group, IGMP version, and ports
associated with each group.
The packet capture in Example 2-9 shows the membership report generated from the host with the
MAC address of 0x000F.F7B1.67E0. Notice how the destination MAC and destination IP are those of
the multicast group the host is interested in receiving. The IGMP snooped mrouter port entry ensures
this IGMP membership report is forwarded to the multicast router for processing, if necessary. See
the next section on maintaining group membership.
Example 2-9 IGMP Membership Report Packet Capture
Click here to view code image
Ethernet Packet: 60 bytes
Dest Addr: 0100.5E40.0707, Source Addr: 000F.F7B1.67E0
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5, TOS: 0xC0 (Prec=Internet Contrl)
Length: 28, ID: 0x0000, Flags-Offset: 0x0000
TTL: 1, Protocol: 2 (IGMP), Checksum: 0x051D (OK)
Source: 192.168.12.20, Dest: 224.64.7.7
IGMP VersionType: 0x16, Max Resp: 0x00, Checksum: 0x02B8 (OK)
Version 2 Membership Report
Group Address: 224.64.7.7
The output in Example 2-10 shows several hosts connecting to the multicast group.
Example 2-10 show ip igmp snooping groups Output
Click here to view code image
Switch#show ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
12 224.0.1.40 igmp v2 Gi0/15
12 224.64.7.7 igmp v2 Gi0/1, Gi0/2,
Gi0/4, Gi0/15
Maintaining Group Membership
As hosts are added to or removed from the multicast group, the switch manages the interaction. The
switch does not notify the router of any additions or removals to the group, with the exception of the
last host. If there is only one host and it leaves the multicast group, the switch immediately sends a
group leave message to the upstream router. One of the interesting aspects of this message is that the
switch spoofs the IP address of the last client. Look carefully at the output in Example 2-11 .
Example 2-11 IGMP Leave Capture Output
Click here to view code image
Ethernet Packet: 60 bytes
Dest Addr: 0100.5E00.0002, Source Addr: 0013.19C6.A60F
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x6, TOS: 0xC0 (Prec=Internet Contrl)
 Length: 32, ID: 0x0000, Flags-Offset: 0x0000
TTL: 1, Protocol: 2 (IGMP), Checksum: 0x7745 (OK)
Source: 192.168.12.40, Dest: 224.0.0.2
Options: Length = 4
Router Alert Option: 94 0000
IGMP VersionType: 0x17, Max Resp: 0x00, Checksum: 0x01B8 (OK)
Version 2 Leave Group
Group Address: 224.64.7.7
The benefit of this behavior is that when the last device leaves the multicast group, the router does
not have to wait for a timeout. Notice also that the MAC address of the source in the packet in
Example 2-11 is the MAC address of the switch as depicted in the show interface Gi0/12 output in
Example 2-12 . This is the mrouter interface for this segment.
Example 2-12 show interface Output
Click here to view code image
Switch#show interface Gi0/12
GigabitEthernet0/12 is up, line protocol is up
Hardware is Gigabit Ethernet, address is 0013.19C6.A60F (bia 0013.19C6.A60F)
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
Configuring IP IGMP Snooping
The configuration could not be easier for newer Catalyst or Nexus product switches. The command
is as follows:
Click here to view code image
C2970(config)#ip igmp snooping
Here is the best part—it is on by default and obviously not necessary to type the previous
command. You can confirm that IGMP snooping is functional and verify the specific operating
parameters with the show ip igmp snooping command, as demonstrated in Example 2-13 .
Example 2-13 Confirming IGMP Snooping Functionality and Parameters
Click here to view code image
Switch#show ip igmp snooping
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood query count :2
Robustness variable :2
Last member query count : 2
Last member query interval : 1000
The output was truncated for brevity, but the IGMP snooping information will be displayed per
VLAN.
 The Process of Packet Replication in a Switch
Nearly all the protocols required to accomplish multicast forwarding are open standards, ratified
by working groups like the IETF. However, the actual process of forwarding packets through a
network device is not an open standard. The same is true of unicast packets. The way each
manufacturer, or in some cases product lines, implement forwarding is what differentiates each
platform from the next.
At the heart of IP multicast forwarding is the packet replication process. Packet replication is the
process of making physical copies of a particular packet and sending a copy out any destination
interfaces in the derived forwarding path.
What makes the process of replication so different from platform to platform is where the
replication occurs. Each Cisco networking platform handles this process a little differently. Many
routers use centralized processing to perform replication. Other more advanced routers and switches
with distributed processing require specialized application-specific integrated circuits (ASICs) to
perform packet replication and forwarding from one line-card to another. At the beginning of the
Internet, the key objective of packet handling was to simply forward packets.
Packet forwarding at wire speed required the specialization of ASIC processing. As features and
applications embedded on routers and switches grew (including critical components in modern
networks like QoS, MPLS, multicast, SNMP, flow reporting, and so on) so did the need for packet
replication and treatment at wire speed. Without ASICs, router processors would be overwhelmed by
packet handling requirements. Cisco Systems spent over 25 years developing custom ASICs, many
specifically for packet replication needs. With that understanding, the router manufacturer must make
a choice about where and on which ASIC(s) to replicate packets. This is especially true in distributed
routing and switching platforms. A distributed platform uses ASICs throughout the device to push
forwarding decisions as close to the interface as possible.
Some distributed platforms may forward incoming multicast packets to the central processing card.
That card may take special action on the packet, replicate the packet, or forward to other line-cards
for replication. If replication occurs on the central processor, then the replication model used is
centralized replication and acts as a traditional bus. In a centralized replication model, resource
pressure occurs on the central processor and centralized resources like memory. Depending on the
size of the multicast deployment or the number of packets requiring replication can result in serious
performance problems for control plane traffic.
Other distributed platforms may use the ASICs associated with the inbound interface or line card to
perform replication. This is known as ingress replication . In this case, the incoming interface line
card replicates the multicast packet and sends copies via a fabric toward the exit interfaces in the
path. Ingress replication distributes resource pressure across multiple processors and may still
require occasional forwarding by the central processor depending on enabled features.
The ASICs associated with the exit interfaces can also perform replication. This, of course, is
egress replication . In some instances, replicating only at the egress interface could mean an obvious
loss in efficiency; however, exit line cards in many models terminate encapsulated multicast packets
destined for certain domains. This means that the egress line card can be an ideal point of replication
because that particular card might have many interfaces with subscribed receivers downstream.
Note
 Downstream is the direction flowing away from the sender, toward the receiver. Fabric-facing
ASICs on these cards will take on the role of replication.
Platforms may implement a combination of these replication methods, centralized, ingress, and
egress. This is known as distributed replication. An incoming interface ASIC may perform one level
of replication and send one packet copy to each line card with exit interfaces in the forwarding tree.
The egress line cards can then create additional copies, one for each interface on that card in the path.
This method further distributes resource pressure across as many ASICs as possible. Figure 2-11
represents a basic distributed replication model using replication on both the incoming line card and
the outgoing line card. (This is a common model used in Cisco devices, for example the Catalyst
6500 switch line.)

Figure 2-11 Packet Replication

The important thing to remember is that each manufacturer and each platform handles replication
differently. To be truly competitive, each manufacturer must perform replication in a safe and efficient
manner. That means the platform must forward as quickly as possible, while preventing loops and
protecting precious control-plane resources. Any architect or engineer seeking to deploy IP multicast
technologies should pay special attention to the replication process of each platform in the network
path, as well as any specialized hardware and software feature enhancements.
Protecting Layer 2
IGMP snooping is a mechanism that we configure on a switch to minimize the impact of multicast
traffic being directed to devices that are not interested in receiving it. This feature helps protect not
only the infrastructure resources, but the devices that are attached to the network. Another feature that
is well worth mentioning and will help to ensure the successful operation of your network is storm
control .
Storm Control
Data storms in networks can be generated in several different ways, including an intentional denial
of service (DoS) attack, a defective network interface card (NIC), a poorly programmed NIC driver,
and so on. In order to prevent broadcast, multicast, or even unicast traffic from overwhelming a
switch by an inordinate amount of traffic, the storm control feature offers the capability to set
thresholds for these types of traffic on a per-port basis.
Configuration options are on a port basis and offer the capability to specify traffic based on the
percentage of bandwidth, bits per second (BPS) or packets per second (PPS). If the threshold is
reached, you can either send a Simple Network Management Protocol (SNMP) trap message or shut
down the port by placing it in an error-disable state. The configuration parameters are as follows:
Click here to view code image
storm-control broadcast level <0.00 - 100.00> / bps / pps
storm-control multicast level <0.00 - 100.00> / bps / pps
storm-control unicast level <0.00 - 100.00> / bps / pps
storm-control action trap
storm-control action shutdown
In the following example, the switch will be configured to send a SNMP message when the
broadcast level exceeds 50 percent:
Click here to view code image
Switch(config)#interface gigabitEthernet 0/2
Switch(config-if)#storm-control broadcast level 50
Switch(config-if)#storm-control action trap
The following is the SNMP message generated when the broadcast level has been exceeded:
Click here to view code image
%STORM_CONTROL-3-FILTERED: A Broadcast storm detected on Gi0/2. A packet filter
action has been applied on the interface.
You also have the ability to place the port in an error-disable state using the following command:
Click here to view code image
Switch(config-if)#storm-control action shutdown
The following output depicts the messages shown in the event of a port shutdown:
Click here to view code image
%PM-4-ERR_DISABLE: storm-control error detected on Gi0/2, putting Gi0/2 in
err-disable state
%STORM_CONTROL-3-SHUTDOWN: A packet storm was detected on Gi0/2. The interface has
been disabled.
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state
to down
%LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to down
We mentioned DoS attacks earlier in this section. When configuring the storm-control action
shutdown command, you may have to manually enable the ports in the event the port is disabled.
Using the errdisable recovery commands helps to mitigate that problem:
Click here to view code image
Switch(config)#errdisable recovery cause storm-control
Swtich(config)#errdisable recovery interval 30
The following output shows the logging message after recovery:
Click here to view code image
2d07h: %PM-4-ERR_RECOVER: Attempting to recover from storm-control err-disable
state on Gi0/2
2d07h: %LINK-3-UPDOWN: Interface GigabitEthernet0/2, changed state to up
2d07h: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed
state to up
Note
Use caution when setting storm levels because you may inadvertently create your own DoS attack
and deny legitimate traffic.
Summary
The process of communication between devices on an IP network requires the handling or
encapsulation of data at each layer of the OSI model. Packets are composed of MAC addresses, IP
addresses, port numbers, and other necessary information. Multicast at Layer 2 has unique
requirements regarding MAC addresses and the way IP addresses are mapped to them. In the mapping
process, 5 bits of the IP address are overwritten by the OUI MAC address, which causes a 32-to-1 IP
multicast address-to-multicast MAC address ambiguity. Client devices on the network use Internet
Group Management Protocol (IGMP) to signal the intent to receive multicast streams and, in most
cases, use IGMP to send leave messages. Modern switches have the capability to “snoop” or listen to
IGMP messages and build appropriate forwarding tables. Timely delivery of messages is the most
important role of the network and protecting those resources are critical to that function. Storm
control can be used to aid in protecting network elements by limiting the types of traffic.
Understanding the intricacies of how Layer 2 devices deliver multicast messages internally will help
you in building an infrastructure to support your business initiatives.
References
Request for Comment (RFC) 1054: Host Extensions for IP Multicasting
RFC 1112: Internet Group Management Protocol, Version 1
RFC 2236: Internet Group Management Protocol, Version 2
RFC 3376: Internet Group Management Protocol, Version 3
RFC 4604: Internet Group Management Protocol, Version 3 and Multicast Listener Discovery
Protocol Version 2 (MLDv2) for Source-Specific Multicast
RFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM)
Chapter 3. IP Multicast at Layer 3
Chapter 3. IP Multicast at Layer 3
As discussed in Chapter 1 , many unique applications leverage multicast for efficient packet
delivery. In most cases, these applications use the network merely as transport for application data.
Multicast senders and receivers are typically IP host machines that run these applications.
Because of the abstraction of the logical layer from the physical in the OSI model, almost any
computing device can be a multicast host. Potential multicast hosts include set-top cable boxes,
smartphones, tablets, laptops, personal computers, servers, routers, and so on. With this kind of
ubiquity, an engineer might assume that a fully converged IP unicast network is simply multicast ready
and that hosts may begin participation in multicast by simple virtue of the host’s IP connectivity.
Unfortunately, that assumption is incorrect. It is true that most IP devices have some minor inherent
multicast capability built in, such as support for specific link local applications. However, most
operating systems do not come preconfigured to participate in specific administrative multicast
groups; that function is dictated by the level of multicast participation (described by IETF RFC 1112)
and by any multicast-enabled application(s) running on the host device.
It is important to understand multicast networking from the perspective of the IP host. It is equally
important to understand which groups may apply to the operating system specifically and which may
apply to specific applications. IP hosts that are fully multicast-aware must interact with the network to
manage the flow of multicast packets, maintaining the highest level of efficiency in packet flow. After
this interaction, network devices can overlay an IP multicast forwarding topology on top of the
established IP unicast network, similar to other technologies like MPLS or IPSec VPNs.
In this chapter, we explain the functionality of clients and servers and what constitutes membership
to a group. You learn about the different types of multicast trees and how they are built using protocol
independent multicast (PIM). Finally, we explain the relationship between routing and forwarding and
what this looks like from the perspective of a Layer 3 device. The elements in this chapter are critical
to understanding how multicast works. Be sure you have a good understanding of what is explained in
this chapter before you move on.
Multicast Hosts
Most major multicast applications function in a specific client/server model. Many engineers make
the mistake of assuming that a server is always a network multicast sender, and that clients are the
receivers. Remember, multicast application flow models (one-to-many, many-to-one, many-to-many)
vary widely depending on the needs of the application.
In a many-to-many implementation, it is not uncommon for servers to both send and receive
multicast messages. Clients in a many-to-one model may be the multicast packet senders, updating a
single server acting as a receiver. Another one-to-many application may support the traditional server
as sender, and clients as receivers (host model). More intricate still are multicast applications that
include these functions only within the networking infrastructure, applications that have no traditional
IP hosts listening to or sending to the infrastructure multicast groups. These applications often enable
network operations or network transport of other packets. This warrants an exploration of how
clients, servers, and network devices support host-based multicast applications, as well as which
established IP multicast groups (or group blocks) are used to identify these applications.
 Networked Groups: Client/Server
An IP multicast group is also known as a host group . The original idea behind a host group was
that one IP host, perhaps a server, would act as a source, sending IP datagrams toward hosts acting as
receivers. The host group is the identifier for those hosts. It is accepted that there are no restrictions
on the hosts that can participate in a group or on where those hosts are located. All hosts in the host
group are equal, and any host may send packets toward the group, regardless of group membership. A
host may also be interested in, or send packets to, more than one group at any given time. To manage
this process, hosts need to have a dynamic mechanism to join or leave a group.
Chapter 2 introduced the basic concept of multicast routing, switching, and forwarding. Routers
that act as gateways must have a way of knowing if a host on a given segment wishes to receive
multicast packets. Gateway routers need that information to build forwarding trees with other routers
in the forwarding path between sources and receivers. Without this membership information, routers
could not build a multicast routing or forwarding tree. Consequently, a join or leave by an IP host in
the group is the mechanism used to notify the network of membership to a specific group.
Note
It is important to note that the IGMP RFC language specifically calls these membership reports
join/leave messages . However, to avoid confusion with PIM join/prune messages, many Cisco
documents simply refer to the IGMP join/leave as a membership report . Both are accurate; this text
uses the RFC terminology.
Hosts must manage group membership dynamically. A host may join a group at any time and may
also leave at any time, or it can also simply leave through natural attrition with timers. Hosts can
participate in many groups at once. Additionally, host group numbers can change, if necessary. Some
host groups are permanent, meaning the group is assigned a “well-known address,” whereas other
host groups can be dynamically assigned through dynamic group assignment protocols or
applications. IPv4 hosts that need to join and leave host groups do so by sending updates to routers
through Internet Group Messaging Protocol (IGMP), and IPv6 hosts use Multicast Listener Discovery
(MLD). RFC 1112 specifies three levels of IP multicast host interest: levels zero through two. Table
3-1 shows the differences between each host level.
 Table 3-1 Multicast Host Support Levels
Each of the various host operating systems can accommodate any of these three levels of multicast
participation. Host and server operating systems can also use Dynamic Host Configuration Protocol
(DHCP) and Multicast Address Dynamic Client Allocation Protocol (MADCAP) services to
dynamically assign IP addresses and IP multicast group assignments for certain applications. To learn
more about host multicast configuration, consult the operating system user manual for the device in
question.
Network Hosts
In certain cases, network devices (routers and switches) can function as either an IP multicast
receiver or sender as though they were a networked host system. For the most part, the applications
that require network device participation in the group are related to network infrastructure. In fact,
most of the IP multicast communication between network hosts is for protocol intercommunication,
and much of this traffic only travels between network devices connected to a common local segment.
The Local Network Control block of addresses facilitates this communication; these addresses are
universally assigned and managed by Internet Assigned Numbers Authority (IANA). Routing
protocols, such as OSPF and EIGRP, are common examples of this type of IP multicast traffic.
Note
Many protocols require special configuration and packet handling on non-broadcast media. Layer 2
non-broadcast domains, like Frame Relay, do not forward broadcast or multicast packets to all
destination ports by default. Additional considerations for many protocols, including Enhanced IGRP
(EIGRP), are often necessary within an OSI Layer 2 domain.
There are other important infrastructure protocols that use multicast communications and require
packets to flow beyond local segments. Some of these protocols may not need routing beyond a local
router or switch, from one local network to another. A fully functional IP multicast network is
requisite for those protocols that require communication to travel beyond a particular networking
device. Example infrastructure protocols that need full network forwarding are multicast virtual
private network (mVPN), heartbeat and cluster applications, and virtual extensible local-area
network (VXLAN).
Note
The original VXLAN standard uses IP multicast for infrastructure communications—broadcast,
unicast, and multicast messages (BUM). More recent standards can also use unicast protocols as
well.
Some infrastructure protocols have specific IANA assigned host groups from the Internetwork
Control, Ad-Hoc, or other multicast blocks. Other protocols require domain-specific administrative
assignment and management from the Administratively Scoped IPv4 block or private IPv6 ranges. For
troubleshooting purposes, network administrators may simply want to join a network device to a
particular group. The network device then participates to the extent of its required capabilities in any
multicast groups that have been assigned to it. This means that each IP multicast packet must be
decapsulated, read, and sent to the device processor for additional processing, if the device is a
member of the destination host group.
Multicast Routing: An Introduction to Protocol Independent Multicast and Multicast Trees
A routing protocol is used to facilitate communication between devices on different segments of a
network. Providing a method of communication might be the primary function, but there are other
purposes for a routing protocol, including loop prevention, path selection, failure detection,
redundancy, and so on. Originally, multicast required a unique routing method that was completely
autonomous to the unicast routing protocol. Distance Vector Multicast Routing Protocol (DVMRP)
and Multicast Open Shortest Path First (MOSPF) are two examples of these protocols. Specific
multicast routing protocols are no longer required because you can take advantage of the underlying
unicast routing protocol. Consequently, DVMRP and MOSPF have fallen out of favor.
A unicast routing protocol is forward-looking, and the routing information or routes stored in the
routing database provide information on the destination. The opposite is true for multicast routing.
The objective is to send multicast messages away from the source toward all branches or segments of
the network interested in receiving those messages. Messages must always flow away from the
source, and never back on a segment from where the transmission originated. This means that rather
than tracking only destinations, multicast routers must also track the location of sources, the inverse of
unicast routing. Even though multicast uses the exact inverse logic of unicast routing protocols, you
can leverage the information obtained by those protocols for multicast forwarding. Why? Because a
multicast source is an IP host, a possible unicast destination, whose location is tracked by the unicast
routing table, like any other IP host in the network.
This allows a network to avoid using another full routing protocol, minimizing the memory space
that needs to be consumed. All of the functionality that is built into the unicast routing protocol,
including loop prevention, path selection, failure detection and so on, can be used for multicast.
Modern IP multicast routing uses protocol independent multicast (PIM), which leverages unicast
routing information, to forward messages to receivers. The process of determining where the
multicast messages are to be sent is referred to as building the tree .
Seeing the Forest Through the Trees
Anyone who engages in the study of networking inevitably encounters the concept of network trees.
For example, Spanning Tree Protocol is a well-known tool for switches to build Layer 2 forwarding
trees that are devoid of network loops. Trees are important because they allow routers and switches
to calculate forwarding tables that follow a prescribed and specific path for frames and packets
without making mistakes or causing network loops. In fact, the design of complex forwarding chips
known as application-specific integrated circuits (ASICS), the “special ingredient” to hardware
forwarding, depends on complex tree mathematics and discrete algebraic logic gates.
Trees are also convenient in that they can be visually represented. Visual trees can make complex
forwarding decisions easier to understand by human beings. But what is a network tree really and
why are they important? This section introduces the uninitiated to basic tree theory and, in particular,
to those trees used in multicast forwarding. Understanding this information is a fundamental
requirement for understanding how multicast protocols create loop-free forwarding topologies.
What Is a Network Tree?
Trees and tree building are an important part of mathematics and computer science.
Mathematically, a network tree is essentially a graph, or directed graph (digraph) , that represents a
hierarchical logical structure. Like real trees, graphical trees have roots, branches, and leaves.
Leaves always diverge away from the root of the tree. Figure 3-1 depicts a network that is translated
into a graph with a root, branches, and a leaf. The graph is directional because traffic is forwarded
from R1 and toward Host B, the end of the network tree being the last-hop router (LHR), or R7.

Figure 3-1 Network Depicted as a Digraph

The root of a tree is the beginning of the graph. A branch is anywhere the tree diverges into two or
more separate paths and a leaf is any place in which the tree ends. Each of these components can be
represented mathematically, through mechanisms such as algebraic Boolean equations.
Network devices share information with each other in order to build trees. A network tree allows
routers and switches to act together in creating forwarding paths. The network can build the
forwarding path based on any desirable outcome (such as loop avoidance, efficiency, shortest path
management, predictive failover, and others). Although it is true that each network device can make
separate decisions, the hope is that the network will collectively build trees that map ideal paths
through the network.
One example of a network tree are the shortest path trees built by Open Shortest Path First (OSPF)
routers. OSPF routers build a database of possible paths from each router interface (root) to each
possible IP destination (leaf). There may be many paths to a destination. The router compares and
then ranks each path and creates a list of shortest (often meaning fastest) paths. Messages are
forwarded toward the destination using the best path. The next-best paths are kept in memory so that
the router may failover to a secondary path if the primary path becomes unusable.
Multicast routers make extensive use of network trees. The primary purpose of a multicast tree is to
build an efficient loop-free forwarding path from the source of the multicast stream toward all the
receivers. Looking at the entire network is a unidirectional way to look at the end-to-end path and not
just next-hop in the forwarding path, which is the local view on any given network router.
The root of the tree from the perspective of the network is the router closest to the source (server)
of the packet stream. A leaf is any router with an attached IP receiver (client) for the given stream. A
branch in a multicast tree is any router that must perform replication to connect the root to the leaves
that are not in the same segment.
Looking at each individual router, the tree is built from the interface(s) closest to the source toward
the list of interfaces that are in the path, including leaves and branches. Understanding multicast trees
requires an understanding of how routers represent each component of the tree, how they build a
loop-free topology, and how multicast messages are forwarded to the destination.
Concepts of PIM Group States
Spanning Tree Protocol is a well-known tool for switches to build Layer 2 forwarding trees that
are devoid of network loops. Multicast trees serve the same purpose. These trees are built by the PIM
protocol. Command line routers cannot represent the tree visually, just like STP on command line
switches. Instead, routers create and display a state table, which represents the state of each multicast
tree maintained by the router. You can display the IP multicast state table in most of the Cisco
platforms using the show ip mroute command, as demonstrated in Figure 3-2 .
 Figure 3-2 Displaying the IP Multicast State Table with show ip mroute
The output of the command is divided into two parts, network flags and multicast group state along
with interface flags. The first part of the output provides generic platform and multicast state flags.
These flags change based on the platform consideration and provide the information of multicast flow
in the multicast group state section.
The multicast group-specific information in the multicast group state is (*,G) and (S,G). This
provides tree information for each maintained multicast flow in the form of a “state table.”
The RP is the rendezvous point for the multicast group, which is discussed in greater detail later in
the section “Two Types of Trees .”
Flags provide information such as the type of multicast stream and the control-plane information in
use. These flags change slightly based on platform, and it is important to refer to the definitions in the
first part of the output to clearly understand this information.
Note
Routers use reverse path forwarding (RPF) checks to keep the multicast topologies loop-free. At
its most basic, an RPF check is a comparison of incoming packets to the vector established in the
unicast routing table for the source of the packet. It is the inverse of a unicast forwarding lookup,
being more concerned with where the packet came from rather than where it is going. In this example,
the RPF check is in the direction of the RP. RPF checks are discussed in more detail in the subsection
“Reverse Path Forwarding .”
Outgoing interface list (OIL) and incoming interface list (IIL) are also provided in this output. The
OIL lists the outgoing interfaces local to the node for the multicast state entry. The IIL in the output
shows the incoming interface list for the multicast state for this node. These two lists are created by
routers after the RPF check has been performed.
Generally speaking, show ip mroute is the first command that an administrator executes to
understand the state of multicast flow on the Layer 3 device.
The (*,G) State Entry
A (*,G) entry in an mroute table represents a router’s relationship to the leaves of a tree.
Remember that IGMPv1 and IGMPv2 hosts use the (*,G) to signal intended membership to upstream
routers. The router adds the (*,G) to the mroute table. Figure 3-3 shows an example network in which
a host is connected to Router 7 (R7) and is sending an IGMP join request for multicast group
239.1.1.1. The sender is connected to R3 and has an IP address of 192.168.20.1.
 Figure 3-3 Example Multicast Topology
Examine the output from the show ip mroute command on R7 in Example 3-1 .
Example 3-1 show ip mroute Command Output
Click here to view code image
R7#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 (*, 239.1.1.1), 10:50:13/00:01:56, RP 192.168.1.1, flags: SJCF
Incoming interface: Null, RPF neighbor 0.0.0.0
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:35:17/00:02:22
The table output shows that R7 has learned of group 239.1.1.1 and the router calculating the tree
knows that the host members are downstream from interface FastEthernet1/1 . In this case, the
outgoing interface represents the path toward the host receivers. Although this router has only one
leaf-facing interface, it is possible to have many downstream interfaces, consequently creating tree
branches. All of the leaf-facing interfaces are added to an outgoing interface list (OIL). Using PIM
messaging, the router forwards this (*,G) entry to routers upstream. Each PIM router in the path adds
the (*,G), and the interface that the update was received on to the OIL for that multicast group.
The (S,G) State Entry
The (S,G) entry in the mroute table represents the router’s relationship to the source of the
multicast stream. In order to build a tree with an (S,G) the router needs to receive and identify
packets from the source, or receive some type of notification either from the network or from hosts
using an (S,G) join via IGMP. After a source for a group is known by the router it adds the (S,G) to
the table using the show ip mroute command, as demonstrated in Example 3-2 .
Example 3-2 (S,G) Entry Added to the mroute Table
Click here to view code image
R7#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 10:50:13/00:01:56, RP 192.168.1.1, flags: SJCF
Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.2
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:35:17/00:02:22
(192.168.20.1, 239.1.1.1), 01:55:30/00:03:26, flags: CFT
Incoming interface: FastEthernet0/0, RPF nbr 192.168.2.2
Outgoing interface list: FastEthernet1/0, Forward/Sparse, 01:55:30/00:03:12
In this output (using the previous example topology), the router has received packets destined to
group 239.1.1.1 from host 192.168.20.1. The router updates the table, which now shows that the
(*,G), entry (*, 239.1.1.1) has an incoming interface of FastEthernet0/0 with Reverse Path
Forwarding (RPF) Neighbor (nbr) 192.168.2.2. This indicates the router has determined that
192.168.20.1 is upstream on interface FastEthernet0/0 , which is not in the path of the leaf, using a
RPF check. The (S,G) entry (192.168.20.1, 239.1.1.1) also has an incoming interface and an OIL.
Routers can forward packets using either the (*,G) or the (S,G) entries, as long as the paths are
determined to be loop-free. In fact, each type of entry represents a different type of tree; the incoming
and outgoing interfaces being the path of the tree from the root, to branches, and finally to the leaves.
These two different types of trees are discussed in the next section.
Reverse Path Forwarding
Under normal unicast routing rules, packet-forwarding decisions are based on the destination
address of the packet arriving at a router. The unicast routing table consists of learned networks and
the associated exit interfaces for each destination network. Thus, the unicast routing table is used for
destination lookups by routers so that each packet is forwarded in the most appropriate direction. The
primary responsibility of each unicast routing protocol is to find and populate the routing table with
the best path toward the destination, while preventing any packets from looping back toward the
packet sender (source). The router’s primary role is to select paths from among many protocols, again
ensuring a loop-free topology.
Using IP multicast, the router forwards the packet based on a lookup of where the source is, the
exact reverse of the unicast forwarding methodology. The router’s multicast forwarding state runs
more logically by organizing tables based on the reverse path, from the receiver back to the root of
the distribution tree. Consequently, the multicast network is a true overlay of the unicast network and
even uses the unicast routing table to ensure a loop-free multicast forwarding tree. This process is
known as reverse path forwarding (RPF). For (*,G) entries, the root of the distribution tree is the RP.
The RP is at the center of the PIM sparse-mode state logic and it maintains the path toward all
sources and receivers in each sparse-mode multicast domain. You will learn more about RP
functionality in the PIM section. For the (S,G) entries, the root for the distribution tree is the router
that connects to the multicast source. In short, incoming multicast packets will not be
accepted/forwarded unless they are received on an interface that is the outgoing interface for the
unicast route to the source of the packet. Figure 3-4 and Figure 3-5 represent this process occurring
on R4.
Figure 3-4 shows a multicast packet coming inbound to R4 on interface E0/0. The source IP of the
multicast sender is 192.168.20.1. The router performs an RPF lookup on that source to check that
E0/0 is indeed in the direction of the route for network 192.168.20.1. A show ip route on R4 shows
that the IP unicast network 192.168.20.0/24 is in fact located via E0/0. The show ip rpf output for
source 192.168.20.1 also shows that the router has confirmed the reverse path to be E0/0 for network
192.168.20.1. With this confirmation, the router can now confidently forward the multicast packet,
knowing that a network loop is unlikely.
 Figure 3-4 Multicast Packet RPF Success
Figure 3-5 shows this same process, except that for some unknown reason the source multicast
packet is received on interface E0/2. Using the same lookup information, the router can easily
determine that the reverse unicast path for network 192.168.20.0 is not in fact located out E0/2. This
indicates that there is likely a forwarding loop in the multicast topology. This can occur for many
reasons, especially in the event of misconfiguration. The router drops this packet to prevent further
propagation of the multicast packet loop. In this case, the PIM tree has served its purpose and
prevented the router from creating or continuing a network loop.
 Figure 3-5 Multicast Packet RPF Failure
Note
This section is meant only to introduce you to the concept of RPF checking. For a more in-depth
discussion of RPF checking and the associated mechanics, see Chapter 5 .
Two Types of Trees
The two types of trees used in multicast networks to control the distribution of traffic are source
trees and shared trees . A source tree originates from the device sending the multicast messages. A
shared tree originates from a device in the network called a rendezvous point (RP). The RP manages
information about the sender or source of the multicast messages, but is not the real source of the tree.
When a receiver is interested in getting multicast messages from a stream that uses a RP, its gateway
router contacts the RP, and, in turn, the RP matches the receiver with the real source of the tree. When
the connection is made between the receiver and the source, the RP will no longer be in the path;
more information on that in the following sections.
Source Trees (Shortest Path Trees)
The most common type of multicast tree is the source tree. A source tree is one in which the
network routers build a tree for each (S,G) state in the network. From the perspective of the network,
the root of the source tree is the router closest to the source. The tree extends from the root router in a
direct path toward all of the group members. This creates a tree in which the path might look similar
to the one shown in Figure 3-6 .

Figure 3-6 Source Tree Path

Network trees can sometimes be difficult to understand. This is true regardless of what protocols
are building the tree. As shown in Figure 3-6 , the tree overlays the entire network. This is simple
enough; however, each router in the network must calculate the tree independently based on the
information it has received, whether by dynamic protocol updates (PIM), or by configuration. From
each router’s perspective, the tree is smaller but has a similar structure built on a root, leaves, and
replication points, or branches. In essence, the mroute table entries represent the smaller trees local
to each router.
An incoming interface (the one closest to the source) and an OIL connect the source packets to the
group members. Using reverse path forwarding, the router checks for loops and creates the OIL from
the best (sometimes called shortest) paths from the unicast routing information base (RIB). For this
reason, a source tree is also called the shortest path tree . The path is calculated and added to the
mroute table, which is also called the multicast routing information base (MRIB) .
The tree can only be calculated if there is a valid, sending source; otherwise, it has no root. Any
(S,G) installed in a router’s MRIB essentially represents a source tree. If all the routers in the
network have correctly calculated the direction of the source and all subscribed hosts, following the
path should be as simple as following the packet path from each incoming interface through each OIL
in the network.
A source tree will, of course, branch any time a router must forward group multicast packets for an
OIL with more than one interface. After the local tree (the router’s mroute table) is populated, it
performs any necessary packet replication through the network tree. In the example network, the
source tree is replicated only at R3, as depicted earlier in Figure 3-6 .
Note
Trees are usually drawn to only include Layer 3 (IP) path and replication. The tree does not
generally include replication or flooding that may occur at Layer 2 of the OSI model, because an
mroute entry is not required for this type of same-segment forwarding.
The network continues to build trees for each group and each source. Depending on the location of
the packet sources and the group members, the shortest path may be different for each (S,G) pair. A
separate and distinct tree is maintained for each unique (S,G) entry. Figure 3-7 shows the same
example network with two source trees, one for each (S,G) pair, for groups 239.1.1.1 and 239.2.2.2
respectively.
 Figure 3-7 Distinct Source Trees
Shortest path trees are an efficient way to use bandwidth and links in an IP multicast network;
however, depending on how the tree is constructed (or, in other words, which protocol is building the
tree), the administrative and control-plane overhead can become overly burdensome. For this reason,
the multicast engineers at the IETF introduced another type of network tree: the shared tree.
Shared Trees
A shared tree uses a different philosophy for distributing multicast packets. One problem with a
source tree model is that each router in the path must share and maintain state information. Having a
large number of groups, which consequently results in having a large number of trees, puts additional
strain on control-plane resources.
The shared tree, on the other hand, uses a shared point in the network from which to build the
distribution tree (this is used in PIM sparse mode). This location is called a rendezvous point or RP
and is therefore the root of the tree. The (*,G) state information is shared upstream from the IGMP
member routers to the RP and the routers in the path build the tree from the RP. Each router still uses
reverse path forwarding (RPF) checks to keep the topology loop-free, but the RPF check is in the
direction of the RP, not the source. Figure 3-8 depicts a shared tree built from the root RP to the
routers with host group members.

Figure 3-8 Shared Tree

Notice the RP placement has no relation to the IP multicast source. The RP may or may not be in the
direct path (shortest path) between the group source and the group client(s). In fact, it can be placed
outside of the path entirely. For this reason, a shared tree is also sometimes called a rendezvous point
tree (RPT) .
The advantage to using this type of tree is that all non-RP routers can conserve control-plane
resources during stream establishment or during host maintenance. Each (*,G) is a single tree,
regardless of the location of the source and only one tree is required for the group, even if there are
many sources. This means that each non-leaf and non-RP router need only maintain the (*,G) for the
entire group. In addition, the network path is pre-determined and predictable, which leads to
consistent network operations.
Branches on a Tree
Branches are built when a router needs to send information to multiple destinations that require the
use of multiple outgoing interfaces, such as, for example, more than one interface entry in the OIL.
Remember, we are building a tree and must eliminate any loops that may cause duplicate information
to be sent to a receiver.
Examining Figure 3-9 , we now see two receivers requesting information from the same multicast
stream. Based on the shortest path learned from the routing protocol, R3 becomes a branch in the tree.
In the case of the receiver connected to R6, the decision for R3 only has one option, which is to send
the multicast information to R6. With the receiver connected to R7, R3 has the option of sending it to
R1 or to R4 and needs to decide which neighbor will receive the stream. In this example, the best
path to the client connected to R7 is via the R4-R5-R7 path.

Figure 3-9 Branches

 PIM Neighbors
The primary purpose of PIM is to share multicast source/receiver information and to build loop-
free trees. With most unicast routing protocols, routers need to build neighbor relationships in order
to share information. PIM has the same neighbor requirement as these unicast protocols. The PIM
process begins when two or more routers establish a PIM neighbor adjacency on a given segment. To
begin the adjacency process, any interfaces participating in multicast routing must be configured for
PIM communications. In Cisco IOS, using the ip pim interface command with the selected PIM mode
enables PIM communications on a specific interface.
Routers discover PIM neighbors by sending PIM hello messages to the link-local multicast address
224.0.0.13 out each PIM-enabled interface. The hello messages are sent every 30 seconds to refresh
neighbor adjacencies. Hello messages also have a neighbor hold-time value, typically 3.5 times the
hello interval, or 105 seconds. If this hold time expires without a refresh from the neighbor, the router
assumes a PIM neighbor failure on that link and tears down the associated PIM adjacency. The router
continues to send hello messages on any PIM-enabled links every 30 seconds to ensure adjacency
occurs with any connected routers or if the failed router returns to service.
To improve security, an MD5 hash can be used to authenticate PIM hello messages with neighbors.
You may also choose to add a PIM neighbor filter using an access control list (ACL). This provides
you with the ability to control which devices you will receive PIM messages from.
In Example 3-3 , the output from R4 shows that it has learned about four PIM-enabled neighbor
routers on interfaces Ethernet0/0 through Ethernet0/4. Each corresponding neighbor router also has
PIM enabled on the interface connected to R4. Pay very close attention to the flags indicated by
Mode: in the output.
Example 3-3 PIM Neighbors Table
Click here to view code image
R4#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
L - DR Load-balancing Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.54.5 Ethernet0/0 06:25:54/00:01:33 v2 1 / DR S P G
192.168.42.2 Ethernet0/1 06:27:10/00:01:20 v2 1 / S P G
192.168.41.1 Ethernet0/2 06:27:10/00:01:28 v2 1 / S P G
192.168.43.3 Ethernet0/3 06:27:10/00:01:34 v2 1 / S P G
Designated Routers
A single network interface and IP address may connect to a multipoint or broadcast network, such
as Ethernet. If the network is PIM-enabled, many neighbor adjacencies can occur, one for each PIM-
enabled IP neighbor. If every PIM router on the segment were to attempt to manage the tree state,
confusion and excess traffic could occur. Similar to OSPF, IETF versions of PIM use a designated
router (DR) on each segment. Much like an OSPF DR, the PIM DR manages state information and
PIM updates for all the routers on the segment.
 The DR selection process occurs when all neighbors on a segment have replied to PIM hello
messages. Each router on a segment selects one router to function as the DR. The DR router is chosen
using the PIM DR priority parameter, where the highest priority router is selected as the DR. The DR
priority is configurable and sent in the PIM hello message. If the DR priority value is not supplied by
all routers, or the priorities match, the highest IP address is used to elect the DR, which is the IP
address of the interface sending the PIM message. By default, all interfaces have a PIM DR priority
of 1. All routers on the segment should select the same DR router, consequently avoiding conflicts.
When the DR receives an IGMP membership report message from a receiver for a new group or
source, the DR creates a tree to connect the receiver to the source by sending a PIM join message out
the interface toward the rendezvous point, when using any-source multicast (ASM) or bidirectional
PIM (BiDir), and to the source when using source-specific multicast (SSM). When the DR determines
that the last host has left a group or source, it sends a PIM prune message to remove the path from the
distribution tree.
To maintain the PIM state, the last-hop DR (the DR for the router pair closest to the group receivers
using IGMP) sends join-prune messages once per minute. State creation applies to both (*, G) and (S,
G) states as follows:
State creation of (*,G) tree: IGMP-enabled router receives an IGMP (*, G) report. The last-
hop DR sends a PIM join message toward the RP with the (*,G) state.
State creation of (S,G) tree at source: Router receives multicast packets from the source. The
DR sends a PIM register message to the RP. In the case of the (S,G) entry, this is the DR closest to the
source or the first-hop DR.
State creation of (S,G) tree at receivers: IGMP-enabled router receives an IGMP (S,G)
report. The last-hop DR sends a PIM join message toward the source.
Figure 3-10 shows the efficiency of using designated routers on a LAN segment in a PIM sparse-
mode (PIM-SM) design. In the diagram, the connecting interface on SW1 has a default PIM DR
priority of 1, whereas SW2’s interface has a configured priority of 100.
 Figure 3-10 PIM DR Election
Note
Both SW1 and SW2 are operating in L3/routed mode.
SW2 is selected as DR, and only one PIM register message is sent to the rendezvous point (RP).
The configured DR priority and DR-elected router address for each interface can be shown by
issuing the command show ip pim interfaces in IOS/XE or show pim interface in IOX-XR. For NX-
OS, use the show ip pim neighbors command instead. The output in Example 3-4 is from an IOS
router. Notice the DR Prior field and the DR address fields in the output.
Example 3-4 Displaying the DR Priority and DR-Elected Router Address for Each Interface
Click here to view code image
CR1#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.63.3 Ethernet0/0 v2/D 1 30 1 192.168.63.6
192.168.43.3 Ethernet0/1 v2/S 1 30 1 192.168.43.4
192.168.31.3 Ethernet0/2 v2/S 1 30 1 192.168.31.3
192.168.8.1 Ethernet0/3 v2/S 0 30 1 192.168.8.1
PIM Messages: Join, Leave, Prune, Graft, and Assert
Routers build trees using multicast state information shared between all the IP multicast routers in
the network. Different types of state messages help the router build the tree appropriately. These
messages draw their nomenclature from tree-related words: join, leave, prune, and graft.
The most current version of PIM for IPv4 is PIMv2, whereas PIM6 is the current version for IPv6.
When PIM is enabled globally on Cisco routers, the protocol defaults to PIMv2 and PIM6. PIM uses
negotiated neighbor adjacencies similar to OSPF to build a network of routers for multicast
information sharing.
There are several types of PIM messages, but all contain the same PIM message format or header,
as shown in Figure 3-11 , the key fields for which are described in the list that follows:

Figure 3-11 PIM Message Format

Version is the PIM version used
Type:
 1. Hello message sent to all PIM neighbors and may contain a hold-time value and/or the LAN
prune delay time. The hold-time signifies how long the neighbor will keep the neighbor relationship
without receiving an update. The LAN prune delay is used on multi-access networks for propagation
delay.
2. A register message is sent by a DR or a PIM multicast border router (PMBR) to the RP,
indicating that a source is sending traffic to a particular multicast group.
3. The register-stop message is a unicast message sent by the RP to the DR after the SPT is created.
4. Join/prune messages are sent by routers to the upstream sources and RPs. As the name indicates,
join messages are sent to join a stream and prune messages to leave a stream.
5. Bootstrap messages contain several entries for the election of the bootstrap router (BSR).
6. Assert messages are used to elect the PIM forwarder.
7. Graft messages are used in a PIM-DM environment to indicate the desire to receive a multicast
stream.
8. A graft acknowledge or graft-ack is sent to the graft originator upon receipt of an (S,G) entry.
9. A candidate RP advertisement is used to send advertisements to the BSR.
10. Checksum is a one’s complement sum of the entire message.
Routers and L3 switches running PIM send periodic hello messages on PIM-enabled interfaces to
discover neighbors. These messages are sourced with the IP address of the outgoing interface and are
sent to all PIM routers with the multicast destination address of 224.0.0.13. They contain information
such as the hello period time, hello hold-time, capabilities, IP address, and so on. The packet capture
in Example 3-5 demonstrates a hello message. Pay special attention to the highlighted areas, the
destination multicast addresses at Layers 2 and 3, the PIM version (v2), the DR priority, and the PIM
message type (Hello).
Example 3-5 Hello Message Packet Capture
Click here to view code image
Ethernet Packet: 72 bytes
Dest Addr: 0100.5E00.000D, Source Addr: AABB.CC00.0430
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5, TOS: 0xC0 (Prec=Internet Contrl)
Length: 58, ID: 0x04CB, Flags-Offset: 0x0000
TTL: 1, Protocol: 103 (PIM), Checksum: 0xE818 (OK)
Source: 192.168.43.4, Dest: 224.0.0.13
PIM Ver:2 , Type:Hello , Reserved: 0 , Checksum : 0x23E1 (OK)
Type: 1 , Length: 2 , Holdtime: 105
Type: 20 , Length: 4 , GEN_ID: -389360719
Type: 19 , Length: 4 , DR Priority: 1
Type: 21 , Length: 4 , State Refresh: 16777216
The packet capture in Example 3-6 shows an example of a join/prune message for the group
239.1.1.1. The output also indicates the source of the multicast stream (192.168.8.8) and the number
of sources joined to the group. Although the destination address is the multicast address of
224.0.0.13, the PIM header contains the destination IP address, which is 192.168.43.3, and indicates
a type of join/prune (see highlighted sections). This message was sent from 192.168.43.4 to
192.168.43.3.
Example 3-6 Join/Prune Message Packet Capture
Click here to view code image
Ethernet Packet: 68 bytes
Dest Addr: 0100.5E00.000D, Source Addr: AABB.CC00.0430
Protocol: 0x0800
IP Version: 0x4, HdrLen: 0x5, TOS: 0xC0 (Prec=Internet Contrl)
Length: 54, ID: 0x0508, Flags-Offset: 0x0000
TTL: 1, Protocol: 103 (PIM), Checksum: 0xE7DF (OK)
Source: 192.168.43.4, Dest: 224.0.0.13
PIM Ver:2 , Type:Join/Prune , Reserved: 0 , Checksum : 0x308C (OK)
Addr Family: IP , Enc Type: 0 , Uni Address: 192.168.43.3
Reserved: 0 , Num Groups: 1 , HoldTime: 210
Addr Family: IP , Enc Type: 0 , Reserved: 0 , Mask Len: 32
Group Address:239.1.1.1
Num Joined Sources: 1 , Num Pruned Sources: 0
Joined/Pruned Srcs:
Addr Family: IP , Enc Type: 0 , Reserved: 0
S: 1 , W: 0, R:0, Mask Len: 32
Source Address:192.168.8.8
Join
When a host wishes to join an IP multicast stream, it does so with a join message. A join for
IGMPv2 includes the (*,G) entry, and the router that receives the initial join prepares to join the
larger network tree. Using a PIM join/prune message, the router shares the join with other upstream
neighbors, joining the router to the larger network tree. This process requires the addition of a
rendezvous point (RP) that will be discussed shortly.
Leave and Prune
When a host no longer wishes to receive the stream, it can issue a leave message to the upstream
router. If the upstream router has no other downstream hosts with a desire to receive the stream, it
will remove the associated (*,G) from the MRIB and send a PIM prune message to neighboring
routers. A prune may also be sent if IGMP has not updated the upstream router’s join timer, or if it is a
non-leaf router that is not a part of the network path. As the name implies, a prune essentially cuts the
router from any paths in the large network tree.
Graft
Because multicast networks are dynamic, a previously pruned router may need to rejoin the stream.
In the case of dense-mode operation, the pruned router sends a graft message to upstream neighbors,
informing the network that downstream host(s) once again desires the stream. The graft message is
sent during the three-minute prune expiration time; otherwise, the router will send another join
message.
Assert
 Finally, what happens to a tree when there are two or more routers upstream from a single host or
server? Remember, the purpose of multicast is to create more efficient forwarding over loop-free
topologies. Having two routers sending replicated packets for a single stream while also managing
upstream protocol communication would defeat this purpose. In a situation where multiple routers
have the same distance and metric values, one of the routers must have a way to assert control over
that part of the tree. The router with the highest IP address is the winner and the assert message tells
upstream routers which router should forward the stream. Any router that loses the assert will
suppress multicast tree building for each asserted group until such time as the assert expires, which
may be caused by a failure in the asserting router.
The way routers use joins, leaves, prunes, grafts, and asserts (if at all) depends entirely on the type
of multicast routing protocol being used in the network. This subsection serves only to introduce the
terms as they relate to a network tree. For detailed information on how these messages are used to
build complex topologies, refer to Chapter 7 , “Operating and Troubleshooting IP Multicast Networks
.”
PIM Modes
PIM uses unicast routing information to forward multicast messages. One of the key elements is the
“I” in PIM. “Independent” indicates that any routing protocol can be used to build multicast trees and
forward to the appropriate destination. Forwarding of the multicast messages can operate in the
following modes: dense, sparse, and sparse-dense.
PIM Dense-Mode
In dense-mode (DM) operation, multicast messages are flooded throughout the entire DM network.
When a downstream router receives the multicast packet but does not have a downstream receiver
interested in the multicast stream, it responds with a prune message. Consequently, multicast
messages are flooded and then pruned approximately every three minutes. This can be a serious issue
for large networks or networks with slower connection speeds as in a wide-area network (WAN).
The amount of traffic generated may cause network outages.
This does not mean that DM is bad. It means that you need to use the proper tool for the job. DM is
extremely easy to implement because there is no need to have a RP and consequently no (*,G) entries.
Where DM makes the most sense is in a small network with high-speed connections. The use of the
PIM-DM state refresh feature keeps pruned state from timing out, allowing even greater scalability.
The IETF implementation of PIM dense-mode (PIM-DM) is often referred to as a push model for
tree building. The name is derived from the fact that all dense-mode nodes assume that all other PIM
neighbors have an interest in each source tree. The PIM-DM router floods (pushes) (S,G) path
updates for each PIM neighbor, regardless of expressed interest. PIM-DM routers may have to
process and maintain unnecessary PIM updates, making PIM dense-mode very inefficient for most
multicast implementations. The use of dense mode assumes a very limited number of sources and a
network in which each subnet is likely to have at least one multicast receiver for each (S,G) tree in
the MRIB (multicast routing information base).
In the push model, joins, prunes, and grafts are very important to maintaining a tree. After the (S,G)
tree is flooded throughout the network, any dense-mode routers without downstream listeners will
prune themselves from the tree. The router places the removed path in a pruned state in the MRIB, and
the path is not added to the mFIB (multicast forwarding information base).
 PIM-DM routers that maintain the (S,G) state information must continue to flood multicast traffic
(forwarding) down tree branches that have not been pruned. During the convergence of the PIM-DM
network, unwanted traffic may reach routers that do not require the multicast stream, resulting in these
routers sending the traffic to the bit bucket.
The pruning PIM-DM routers send PIM prune messages back upstream toward neighbors, and
those neighbors then prune that particular tree branch, preventing traffic from flooding on that branch.
This flood prune process repeats every three minutes. Excessive traffic flooding and PIM
management processing make PIM dense-mode very inefficient and undesirable in larger networks.
Tip
In dense mode, the Layer 3 device assumes that all routers in the Layer 3 domain configured with
PIM dense-mode needs the multicast stream, consequently forwarding to all Layer 3 devices. If there
are no directly connected members, the router will send a prune message to the router connected to
the source.
When a new receiver on a previously pruned branch of the tree joins a multicast group, the PIM
DM device detects the new receiver and immediately sends a graft message up the distribution tree
toward the source. When the upstream PIM-DM device receives the graft message, it immediately
places the interface on which the graft was received into the forwarding state so that the multicast
traffic begins flowing to the receiver.
All of this constant communication to maintain the source trees can be burdensome on the network.
For this reason, PIM dense-mode is not optimal and suitable for large-scale deployment. The next
generation Cisco network devices do not have the support for PIM dense-mode. (Nexus platform does
not support PIM dense mode.)
PIM Sparse-Mode
Protocol independent multicast sparse-mode (PIM-SM) is a protocol that is used to efficiently
route multicast packets in the network. In multicast terminology, PIM sparse-mode is an
implementation of any-source multicast (ASM). It interacts with the router’s IP routing table to
determine the correct path to the source of the multicast packets (RPF). It also interacts with IGMP to
recognize networks that have members of the multicast group. As the name implies, it does not depend
on any particular unicast routing protocol. Based on the RFC 4601, the basic mechanism of PIM-SM
can be summarized as follows:
A router receives explicit join/prune messages from those neighboring routers that have
downstream group members. The router then forwards data packets addressed to a multicast group
(G) only onto those interfaces on which explicit joins have been received.
A designated router (DR) sends periodic join/prune messages toward a group-specific rendezvous
point (RP) for each group for which it has active members. The RP acts as the gatekeeper and meeting
place for sources and receivers. In a PIM-SM network, sources must send their traffic to the RP. For
this to work, the router must know where the RP is located, meaning it must know the IP address of
the RP for a specific multicast group. Every group for which the router is receiving joins must have a
group-to-RP mapping. To show this mapping in IOS, use the command show ip pim rp-mapping , as
shown in Example 3-7 .
Example 3-7 PIM RP to Group Mappings
Click here to view code image
 R7#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.168.0.2 (?), v2v1
Info source: 192.168.0.2 (?), elected via Auto-RP
Uptime: 1d15h, expires: 00:02:53
After the traffic is sent to the RP, it is then forwarded to receivers down a shared distribution tree.
By default, when the last-hop router in the tree (the router closest to the receiver) learns about the
source, it verifies the best reachability path to the source from unicast routing table. If a path exists,
then it will send a join message directly to the source, creating a source-based distribution tree from
the source to the receiver. This source tree does not include the RP unless the RP is located within the
shortest path between the source and receiver.
Each router along the path toward the RP builds a wildcard (any-source) state for the group and
sends PIM join messages on towards the RP. When a data source first sends to a group, its DR
(designated router, also the FHR) unicasts register messages to the RP with the source’s data packets
encapsulated within. The RP sends a register stop message towards the FHR, the FHR then sends the
multicast data packets towards the RP. The RP forwards the source’s multicast data packets down the
RP-centered distribution tree toward group members (receivers for the multicast group). The last-hop
router verifies the existence of a more optimal path to the source. This depends on the interior
gateway protocol (IG) and congruent PIM relationships along the path. If such a path exists, a (S,G)
join is sent, and the flow moves to the alternate path as defined by the IGP. Finally, the last-hop router
sends a prune to the RP.
Figure 3-12 and the list that follows review a step-by-step approach of a tree build-up using the
multicast flow in the figure.
 Figure 3-12 PIM Sparse-Mode Tree Build-Up Process
Step 1. Receiver sends an IGMP request to the last-hop router (LHR). The LHR reviews its
configuration for RP information for the requested group and sends a request in PIM control protocol
towards the RP. The RP is a gatekeeper that holds all information on active multicast receivers and
sources.
Note
PIM sparse-mode and this process is based on RFC 4601.
The communication between the LHR and the RP is represented as a shared tree and is referred to
as a (*, G).
Step 2. The (*, G) update is used to provide the RP information of an active receiver for the
multicast group.
Step 3. The source sends the multicast stream to the first-hop router (FHR).
Step 4. The FHR, configured with PIM sparse-mode and relevant RP information, encapsulates the
multicast stream in a unicast packet called the register message and sends it to the RP.
Step 5. In this example, the RP already has an interested receiver that wants to join the multicast
group using the (*, G) entry. Consequently, the RP sends an (S,G) PIM join towards the FHR. It also
sends a register stop message directly to the FHR.
 Step 6. After receiving the register stop message, the FHR sends the multicast stream to the RP as
an (S,G) flow.
Step 7. Based on the interested receiver, the outgoing interface list is populated, and the (S,G)
flow is sent to the LHR via the PIM-enabled interfaces aligned to the unicast routing table. From the
LHR, the multicast packet flows to the receiver.
Step 8. At the LHR, the router checks its unicast routing table to reach the source.
Step 9. If the check verifies an alternate path is more optimal based on the unicast routing protocol,
the (S,G) join is sent to the source from the LHR.
Step 10. The source sends the multicast flow to the LHR via the (S,G) state and is created in the
multicast routing table. When the data flow has migrated to the shortest path tree (S,G), the multicast
LHR sends an RP prune message towards the RP.
PIM Sparse-Dense Mode
Sparse-dense mode was developed to address the issue of distributing RP information in some
dynamic RP mapping environments. For example, when using the Cisco dynamic RP mapping
protocol, Auto-RP, the address of the RP is distributed using dense mode, and additional multicast
streams would use the RP as a shared tree.
One of the challenges with sparse-dense mode occurs during RP failure. If the network is not
configured appropriately, all the multicast traffic reverts to DM, consequently causing undue stress on
the network. If the RP fails, any new sessions requiring the interaction of the RP will also fail. Using
sparse-dense mode (PIM-SD) is one method to ensure delivery of multicast messages for new
connections. In the event of a RP failure, the multicast mode of operation reverts to or falls back to the
least common denominator, which is dense mode (PIM-DM) flooding of multicast messages.
The behavior in a PIM-DM configuration is to flood multicast messages. Routers in the multicast
network without downstream clients interested in receiving the multicast traffic send a prune
message. This becomes a constant flood and prune, which may overwhelm a network with many
senders and/or limited bandwidth. Caution should always be used any time PIM-DM could be
initiated.
Tip
Because of this additional burden of maintaining dense-mode source trees during misconfiguration
or router failures, the authors do not recommend using sparse-dense mode. Additional tools and
features have been developed for Cisco routers to avoid dense-mode.
For this reason, it is desirable to have high availability of RP systems. There are many ways to
achieve this, depending on the PIM mode in use. For information about dynamic RP mapping and
propagation, as well as RP redundancy, please refer to Chapters 4 and 5 .
Multicast Flow at the Leaf
The overall multicast flow is a combination of the Layer 2 and 3 environments. IGMP is the most
common mechanism to control multicast messages at Layer 2, and the PIM control plane is used to
manage multicast traffic to flow from the source to the receiver at Layer 3. Let’s examine the flow of
the multicast tree establishment for a sender and receiver multicast flow at the last-hop router (LHR).
To understand this, let’s look at a slightly different example network, shown in Figure 3-13 . There
are three routers that makeup the network, R1, R2, and R3. R3 is connected to VLAN 8, and this is
where the source of the multicast stream is located. R2 is connected to VLAN 7, and this is where the
client is located.

Figure 3-13 IGMPv2 Example

In this example, the source Sender-1 is sending a multicast stream to 224.64.7.7. Because the
network is configured using PIM dense-mode, the multicast group is flooded and pruned throughout
the network. Using the show ip mroute 224.64.7.7 verbose command demonstrated in Example 3-8 ,
you can see that the ‘P’ flag has been set, indicating that the multicast route has been pruned.
Example 3-8 Verifying a Multicast Route Has Been Pruned
Click here to view code image
R2#show ip mroute 224.64.7.7 verbose
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.64.7.7), 00:12:38/stopped, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/2, Forward/Dense, 00:12:38/stopped
GigabitEthernet0/0/1, Forward/Dense, 00:12:38/stopped
(192.168.8.10, 224.64.7.7), 00:09:37/00:01:18, flags: PT
Incoming interface: GigabitEthernet0/0/1, RPF nbr 192.168.32.3
Outgoing interface list:
GigabitEthernet0/0/2, Prune/Dense, 00:00:35/00:02:24, A
When a host is interested in receiving a particular multicast stream, it sends an unsolicited
membership report to the multicast group it is interested in joining. In our example, it is Receiver-1
(192.168.7.3).
Note
In this example, we have turned off IGMP snooping on the switch for VLAN 7 to better explain the
effect of IGMP on the router.
The high-level steps involved for the host to begin receiving the multicast stream are as follows:
Step 1. The host (Receiver-1) sends a multicast IGMP join report to a group address, 224.64.7.7.
Step 2. The router receives the report from Receiver-1, and, using the debug ip igmp command on
R2, we can see the logging message as shown here:
Click here to view code image
IGMP(0): Received v2 Report on GigabitEthernet0/0/0 from 192.168.7.3 for 224.64.7.7
Step 3. The (*,G) entry (*, 224.64.7.7) is added to the multicast routing table (MRT) —not to be
confused with the maximum response timer . The entry matches packets from any source as long as
the packet is received from an interface that matches the reverse path forwarding (RPF) check. In
dense mode, the route is 0.0.0.0. The output is shown using the debug ip mrouting command on R2:
MRT(0): Update (*,224.64.7.7), RPF /0.0.0.0
Step 4. The router now updates the multicast routing information base (MRIB) table with the
outgoing interface, this is where Receiver-1 is located and the outbound interface list (OIL) is added.
The following output is generated using the debug ip mrib route command on R2.
Click here to view code image
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) midb update: ADD, IDB =
GigabitEthernet0/0/0, next hop = 0.0.0.0
 Step 5. The multicast forwarding information base (MFIB) for IPv4 is now updated with the
appropriate source address (S,G) learned from PIM dense-mode. This can be viewed using the debug
ip mfib ps (Cisco IOS) command:
Click here to view code image
MFIBv4(0x0): (*,224.64.7.7) MRIB update[1]: C K (Modified: )
MFIBv4(0x0): (*,224.64.7.7) GigabitEthernet0/0/0 MRIB update: RF F NS
(Modified: RF NS)
MFIBv4(0x0): (192.168.8.10,224.64.7.7) MRIB update[1]: K DDE
(Modified: )
MFIBv4(0x0): (192.168.8.10,224.64.7.7) GigabitEthernet0/0/0 MRIB
update: RF F NS (Modified: RF NS)
Step 6. Finally, the router performs an RPF check to validate where the sender (Sender-1) is
located. In this example, the interface is GigabitEthernet0/0/1. To view the following output, use the
debug ip mrib route command on R2.
Click here to view code image
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) mroute update:
MOD FLAGS, rpf = GigabitEthernet0/0/1, flag = C0
MRIB: Table = Default, Trans: (192.168.8.10, 224.64.7.7) igmp update
local interest, rpf = GigabitEthernet0/0/1
MRIB: Table = Default, Trans: (*, 224.64.7.7) mroute update: MOD FLAGS,
rpf = Null, flag = 84
MRIB: Table = Default, Trans modify entry: (*,224.64.7.7/32) flags:
set C , success
MRIB: Table = Default, Trans: (*, 224.64.7.7) igmp update local
interest, rpf = Null
Now that the multicast stream is being received by Receiver-1, we can verify the IGMP group
membership on R2 using the show ip igmp groups command, as demonstrated in Example 3-9 .
Example 3-9 Verifying IGMP Group Membership
Click here to view code image
ASR1K-2#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group
Accounted
224.64.7.7 GigabitEthernet0/0/0 00:05:47 00:02:44 192.168.7.3
We can also validate the active state for group 224.64.7.7, because the “P” flag has now been
removed. This is shown using the show ip mroute command, as demonstrated in Example 3-10 .
Example 3-10 Validating Active State for a Multicast Group
Click here to view code image
ASR1K-2#show ip mroute 224.64.7.7
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
 L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.64.7.7), 00:05:19/stopped, RP 0.0.0.0, flags: C
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/2, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/1, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/0, Forward/Dense, 00:05:19/stopped
(192.168.8.10, 224.64.7.7), 00:05:19/00:01:34, flags: T
Incoming interface: GigabitEthernet0/0/1, RPF nbr 192.168.32.3
Outgoing interface list:
GigabitEthernet0/0/0, Forward/Dense, 00:05:19/stopped
GigabitEthernet0/0/2, Prune/Dense, 00:00:39/00:02:20, A
Note
It is important to understand the flags used in the state output given by the show ip mroute
command. Here is an explanation of these flags as used in IOS:
Common flags:
D : PIM state is being processed as a dense-mode flow.
S : PIM state is being processed as a sparse-mode flow.
B : PIM state is being processed as a bidirectional flow.
SSM : PIM state is being processed as a source-specific mode flow.
T : SPT bit set, meaning the router has moved the flow to an (SPT).
C : Connected, when a group member is connected to the router.
L : Local, when a router itself is considered a member of the group.
P : Pruned, a multicast group state has been pruned by PIM but has not yet aged from the mroute
table.
R : RP-bit is set, indicating that the (S,G) flow is currently pointed toward the RP.
F : Register flag appears when the source is being registered to the RP (appears on the FHR).
J : The router has processed a PIM join for the SPT state.
Leaving an IGMP Group
When using IGMPv1, there is no such thing as a leave process. When a host is no longer interested
in receiving a multicast stream, it just stops processing the multicast information, but that doesn’t stop
traffic from being sent! The only way a router can determine if there are valid hosts interested in the
multicast stream is by sending query messages. Query messages are generally sent every 60 seconds
and typically require a timeout interval of three query messages. This means that multicast traffic is
being sent for an additional three minutes to an uninterested host. Yes, that is a terrible waste of
bandwidth!
Example 3-11 shows a packet capture of a membership query message sent from the router to the
devices on the subnet.
Example 3-11 IGMP Membership Query Message Packet Capture
Click here to view code image
Internet Protocol Version 4, Src: 192.168.7.1, Dst: 224.0.0.1
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00:
Not-ECT (Not ECN-Capable Transport))
Total Length: 28
Identification: 0x2116 (8470)
Flags: 0x00
Fragment offset: 0
Time to live: 1
Protocol: IGMP (2)
Header checksum: 0xf05f [validation disabled]
Source: 192.168.7.1
Destination: 224.0.0.1
Internet Group Management Protocol
[IGMP Version: 1]
Type: Membership Query (0x11)
Header checksum: 0xeeff [correct]
Multicast Address: 0.0.0.0 (0.0.0.0)
IGMPv2 and v3 are significantly more efficient at leaving a group. An IGMPv2 or v3 host can send
a leave message to all routers on the subnet, indicating that it no longer wants to receive a multicast
stream. Upon receipt of the leave message, the router stops forwarding the multicast traffic. Example
3-12 shows a packet capture of a host leave message.
Example 3-12 IGMP Host Leave Message Packet Capture
Click here to view code image
Internet Protocol Version 4, Src: 192.168.7.3 Dst: 224.0.0.2
Version: 4
Header length: 24 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT
(Not ECN-Capable Transport))
Total Length: 32
Identification: 0x6d72 (28018)
Flags: 0x00
Fragment offset: 0
 Time to live: 1
Protocol: IGMP (2)
Header checksum: 0x0fb8 [validation disabled]
Source: 192.168.7.3
Destination: 224.0.0.2
Options: (4 bytes), Router Alert
Internet Group Management Protocol
[IGMP Version: 2]
Type: Leave Group (0x17)
Max Response Time: 0.0 sec (0x00)
Header checksum: 0x01b8 [correct]
Multicast Address: 224.64.7.7
The Rendezvous Point and Shared Tree Dynamics
Let’s take a much closer look at sparse-mode operations and the significance of the rendezvous
point. In sparse mode, the RP of a network is always a router. The RP router is not a packet source but
simply a location from which to root and calculate a loop-free topology. The RP can also offload the
processing of network joins and leaves during the initial setup of a multicast stream, saving network
resources by concentrating them in a single location. In the example network shown in Figure 3-14 ,
the clients notify last-hop routers (LHR) (R6 and R7) via IGMP of the intention to join a group. The
LHR routers forward PIM join messages toward the RP, establishing the (*,G) state and the LHR as
leaves in the shared tree.
 Figure 3-14 Forwarding Joins Toward the RP
Each router in the path between the RP and the LHR (which hosts receivers) follows the same
procedure, recording the incoming interface of the join message. The router RPF checks each join
against the location of the RP and adds the joined interface to the OIL. The incoming interface, of
course, will be the multicast-enabled interface with the shortest path to the RP. The join messages
stop at the RP for the shared tree, or if the receiving router already has an (S,G) entry for the group in
the (*,G) join message. Using the show ip mroute command, you can view the conditions of both the
(S,G) and (*,G) entries, as demonstrated in Example 3-13 .
Example 3-13 Displaying the (S,G) and (*,G) Entry Condition
Click here to view code image
R4#show ip mroute 239.2.2.2
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.2.2.2), 00:00:16/stopped, RP 172.16.1.1, flags: SPF
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list: Null
(10.11.11.11, 239.2.2.2), 00:00:16/00:02:43, flags: FT
Incoming interface: Loopback0, RPF nbr 0.0.0.0, Registering
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:00:16/00:03:13
At this point in the process, a shared tree has been constructed from the RP to the gateway routers
(LHRs) in the path. For the example network in Figure 3-14 , the shared tree flows from the root at
the RP to R7. R3 would already have an (S,G) and would therefore share the SPT with R6, and after
it receives packets from a multicast source destined to the group, it begins replicating and forwarding
packets to R6. Remember, the shared tree is represented by the (*,G) entries of the routers in the path
and at the RP.
When a source begins sending packets to the multicast flow, the DR interface on the FHR (R3, or
the router closest to the source) needs to notify the RP that a stream needs forwarding and a source
tree needs to be built. It does this by sending a PIM source register message to the RP. The RP needs
this information in order to join the source tree at the source. The RP is now joined to the SPT, and
packets can be forwarded to the RP, the root of the shared tree for further replication and forwarding.
Figure 3-15 depicts this process.
 Figure 3-15 Source Registration Process
There is a small gap in this explanation: How then are packets forwarded from the source to the
shared tree before the RP has joined the SPT? If the multicast source (server) still sends the first
multicast packets toward its gateway router (in this case R3, the FHR) and R3 forwards the packets
toward the RP, a serious problem could occur. For example, if the packet is forwarded through R1,
but R1 did not get a PIM message yet and will therefore not have a (*,G) or (S,G) entry in its mroute
table, it would drop the packet! Sending the multicast packet toward the RP through normal multicast
forwarding will not work until the RP is joined to the SPT.
To resolve this problem, the router closest to the source must encapsulate the multicast packet
inside of a unicast packet with the IP address of the rendezvous point as the IP destination. In other
words, the multicast stream must be tunneled from the router at the source to the RP.
When configuring multicast on a router, you may have noticed the following message:
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
 This appears when the router learns about the RP and creates the tunnel interface. Upon further
inspection using the show interfaces tunnel 0 command, you see the destination of the tunnel is the
RP 192.168.0.2 and sourced from a local interface, as demonstrated in Example 3-14 .
Example 3-14 show interfaces tunnel 0 Command Output
Click here to view code image
R3#show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: Pim Register Tunnel (Encap) for RP 192.168.0.2
Interface is unnumbered. Using address of Ethernet0/2 (192.168.31.3)
MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 192.168.31.3 (Ethernet0/2), destination 192.168.0.2
Tunnel Subblocks:
src-track:
Tunnel0 source tracking subblock associated with Ethernet0/2
Set of tunnels with source Ethernet0/2, 1 member (includes iterators),
on interface <OK>
Tunnel protocol/transport PIM/IPv4
Tunnel TOS/Traffic Class 0xC0, Tunnel TTL 255
Tunnel transport MTU 1472 bytes
Tunnel is transmit only
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input never, output 00:17:06, output hang never
Last clearing of "show interface" counters 00:21:34
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
4 packets output, 1216 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
Another item of interest is the number of output packets. This indicates multicast packets that were
tunneled to the RP.
The tunnel is known as the Encap Tunnel . To make the encapsulation process more efficient, the
outer unicast header that is added to the multicast is actually the PIMv2 register message that is sent
to the router. In this way, the multicast and the PIM register arrive at the RP at the same time. The RP
strips the PIM register encapsulation from the multicast packets and forwards the packets to any
receivers using the shared tree state(s). Figure 3-16 depicts the tunneling, replication, and subsequent
forwarding of the multicast stream with packet capture output from the links between R1, the RP, and
R5.

Figure 3-16 Shared Tree Forwarding

This process of encapsulating packets in the tunnel is only temporary. When there is a source tree
(S,G) established between the FHR and the RP, the RP actually begins to receive two copies of each
multicast packet, one from the now native source tree, and one inside the unicast encapsulation. This
is obviously not the ideal state for the traffic to be in. When this condition occurs, the RP sends a
register stop message via PIM to the FHR encapsulating the flow. This tells the FHR, in this case R3,
to use only the native source tree to the RP to forward packets. The register stop message conditions
are as follows:
When the RP has receivers in its multicast entry table (*,G) for the new multicast group, the RP
sends an (S,G) join message towards the FHR and then sends a register stop message directly to the
FHR.
When the RP has no receivers, it discards the multicast group register message and sends a
register stop message towards the FHR. Each FHR maintains a register suppression timer that is
initiated by the register stop message. Upon expiration of this timer, the FHR again sends a register
packet to the RP to verify whether there are any active receivers for that group, provided the multicast
source is also still active.
The register stop message with packet capture is shown in Figure 3-17 . This tells the FHR, in this
case R3, to use the native source tree to the RP to forward packets.

Figure 3-17 Register Stop

It may also be of value to examine the encapsulation and register stop process described in Figures
3-16 and 3-17 through a sniffer trace of the packets traveling to and from the RP. Table 3-2 shows a
packet capture on the link between R1 and R2, whereas Table 3-3 shows the multicast packets being
passed down the shared tree on the link between R2 and R5. In this capture, the IP address of the
source is 192.168.8.8, the RP is address 192.168.0.2, and the tunnel source interface on R3 is
192.168.31.3, as shown in Figure 3-16 .

Table 3-2 Packet Capture Between R1 and R2

Table 3-3 Packet Capture Between R2 and R5

The packet trace in these tables shows the flow, explained here by packet sequence number:
1. R3 packages the first packet (Seq. 1 on both traces) in the flow into the PIM register message
and forwards it to the RP through the tunnel. The RP unpacks the inner multicast packet and forwards
it down the shared tree to R5.
2. After the first packet is received, the RP sends a PIM join toward the FHR (R3). Because this
packet is a PIM join, it is sent by the PIM interface closest to R1 with IP address 192.168.21.2 to the
all-routers local multicast group 224.0.0.13.
3. The encapsulation process continues until the RP receives a native multicast packet from the
source to that group, and the RP continues to forward the multicast packets toward R5.
4. The RP receives the native multicast packet via the newly formed source tree from the FHR to
the RP. This packet is also forwarded down the shared tree. Any future copies received in the Encap
Tunnel are squelched.
 5. The RP sends a register-stop message to the FHR, indicating that the (S,G) to the RP is
functional. The FHR no longer uses the encap tunnel for this multicast group.
From a Shared Tree to a Source Tree
When is a shared tree used and when is a source tree used? As shown in the previous section,
multicast flows in a PIM sparse-mode network actually use both types of trees. The initial flow
follows the source tree toward the RP and a shared tree from the RP to the receiver. Even though this
forwarding arrangement completes the flow, that’s not the end of the process. Sending all traffic
through the RP is probably not optimal, especially if the RP is not in the preferred data path from the
source to the receivers, as is the case in the example network shown in Figure 3-16 .
Don’t forget the larger purpose of multicast: to gain more efficiency in the way packets are
forwarded from the source to receivers. The shared-tree forwarding process is designed to create an
efficient loop-free forwarding tree that conserves router memory and other control-plane resources
across the network. To achieve the larger purpose of multicast, however, the network needs to further
optimize the path(s) used for forwarding. To do this, routers only send packets through the shared tree
until the network can properly calculate a source tree from the FHR to all receivers, eventually
bypassing the RP altogether. The ideal state for all multicast flows in a sparse-mode network is an
SPT that takes the most direct path(s) between sources and receivers.
Note
If a shared tree was always used as the distribution point for all traffic, this could create a
significant amount of traffic through the RP and will likely introduce suboptimal traffic flows,
depending on the placement of the RP in the network. It is the default behavior of Cisco routers to
honor the forwarding paradigm of moving packets from the shared tree to the source tree as described
above. When this occurs, the SPT bit is marked in PIM messages for this group, and the T flag
appears in the router’s state entry, as shown earlier in the flag explanation for Example 3-9 .
However, there may be instances where this is less desirable and is therefore a configurable
parameter. This parameter is known as the spt-threshold , and it is calculated in terms of bandwidth
consumed (kbps) by the flow. The default setting on all Cisco routers is a threshold of 0 kbps,
meaning that the router will always transition traffic to an SPT. If there is a reason that warrants
delaying or preventing a stream from switching to an SPT, such as, for example, conserving memory
resources on routers in the SPT path, then the ip pim spt-threshold {kbps | infinity } [group-list
access-list ] command in IOS can be used. The infinity command option can be used to permanently
prevent STP switchover from occurring. When this command option is used, forwarding is completed
only through the shared tree (*,G). In modern networks, memory for SPT calculations is rarely an
issue, but it does exist for those circumstances that warrant it.
Let’s look closer at the tree transition using our network from the diagram in Figure 3-18 , which
includes IP addressing. In the following list we detail the flow of communication, as described
earlier, step-by-step, including router debug output. In this example, a multicast source (multicast
server) for group 239.1.1.1 connected to R3 is using the IP address of 192.168.8.8. A receiver for
239.1.1.1 is connected to R7 and is using the IP address of 192.168.10.10.
 Figure 3-18 Example Network with IP Addressing
1. Source sends to FHR with no receivers: When the source begins to send multicast information,
R3 registers the entry and informs the RP of the stream. This is seen on the RP (R2) using the debug ip
pim command:
Note
R3 is using the IP address of 192.168.31.3.
Click here to view code image
PIM(0): Received v2 Register on Ethernet0/2 from 192.168.31.3 for 192.168.8.8,
group 239.1.1.1
PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1) entry
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of
(*, 239.1.1.1).
PIM(0): Adding register decap tunnel (Tunnel1) as accepting interface of
(192.168.8.8, 239.1.1.1).
Another item of interest is that the RP responds back to R3 from two interfaces because there is an
equal cost path.
At this stage in building the tree, the only routers that have any awareness of the stream are R3, the
router directly upstream from the source, and the RP.
The source is sending a multicast stream, but it does not have any receivers, as verified in the
output from the show ip mroute 239.1.1.1 command demonstrated here:
Click here to view code image
R3#show ip mroute 239.1.1.1
… partial output shown for brevity …
(*, 239.1.1.1), 00:00:14/stopped, RP 192.168.0.2, flags: SPF
Incoming interface: Ethernet0/2, RPF nbr 192.168.31.1
Outgoing interface list: Null
(192.168.8.8, 239.1.1.1), 00:00:14/00:02:45, flags: PFT
Incoming interface: Ethernet0/3, RPF nbr 0.0.0.0
Outgoing interface list: Null
The OIL is Null, which means that nothing is being sent.
Note
Recall the register stop conditions: If there are no established receivers for a group state, the RP
will eventually start sending register stop messages to the FHR. This is the state shown in the show ip
mroute 239.1.1.1 output, and this is why the OIL is Null. Sending the register stop prevents
unnecessary forwarding of any packets when there is no shared tree established for the flow until such
time as there are both known receivers and an active source. The RP discontinues the register stop
messages and allows the registration process to begin anew after it receives a (*,G) PIM join
messages for that group.
From the show ip mroute 239.1.1.1 output, you see the shared tree (*, 239.1.1.1) and the source
tree (192.168.8.8, 239.1.1.1).
R7 currently does not have any knowledge of 239.1.1.1, as seen using the show ip mroute
239.1.1.1 command demonstrated here:
R7#show ip mroute 239.1.1.1
Group 239.1.1.1 not found
When the host connected to R7 desires to join the multicast stream sourced of 239.1.1.1, a series of
events takes place, as follows (note that the multicast source is already active and the FHR starts the
registry process):
2. Receivers join at the LHR: R7 receives the IGMP join message (membership report) from the
attached client and adds it to the IGMP group table, as seen from the show ip igmp groups command:
Click here to view code image
R7#show ip igmp groups 239.1.1.1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
Group Accounted
239.1.1.1 Ethernet0/1 00:00:02 00:02:57 192.168.10.10
 3. LHR establishes the shared tree toward the RP: R7 establishes the (*,G) and sends a join
message to the upstream neighbor (R5), as seen from the following debug messages using the
command debug ip pim :
Click here to view code image
PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1) entry
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Upstream mode for (*, 239.1.1.1) changed from 0 to 1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Received RP-Reachable on Ethernet0/0 from 192.168.0.2
PIM(0): Received RP-Reachable on Ethernet0/0 from 192.168.0.2 for group
239.1.1.1
PIM(0): Update RP expiration timer (270 sec) for 239.1.1.1
PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.75.5's queue
PIM(0): Building Join/Prune packet for nbr 192.168.75.5
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Send v2 join/prune to 192.168.75.5 (Ethernet0/0)
4. RP builds the (*,G) state and receiver entry: Upon receiving the join message generated from
R7, the RP (R2) builds the (*, G) state, as shown in the following debug ip pim message:
Click here to view code image
PIM(0): Received v2 Join/Prune on Ethernet0/0 from 192.168.52.5, to us
PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Add Ethernet0/0/192.168.52.5 to (*, 239.1.1.1), Forward state, by PIM
*G Join
PIM(0): Add Ethernet0/0/192.168.52.5 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM *G Join
5. FHR registers the active source: The RP already received a register packet from the FHR
because it has the (*,G) state with receiver information. The RP sends a (S,G) join message to
224.0.0.13 towards the FHR and then sends a register stop message directly to the FHR. The output
from the RP is shown using the following debug ip pim message:
Click here to view code image
*May 11 21:36:48.311: PIM(0): Received v2 Register on Ethernet0/2 from
192.168.43.3
*May 11 21:36:48.311: for 192.168.8.8, group 239.1.1.1
*May 11 21:36:48.311: PIM(0): Adding register decap tunnel (Tunnel1) as
accepting interface of (192.168.8.8, 239.1.1.1).
*May 11 21:36:48.311: PIM(0): Insert (192.168.8.8,239.1.1.1) join in nbr
192.168.42.4's queue
*May 11 21:36:48.311: PIM(0): Building Join/Prune packet for nbr 192.168.42.4
*May 11 21:36:48.311: PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), S-bit
Join
*May 11 21:36:48.311: PIM(0): Send v2 join/prune to 192.168.42.4 (Ethernet0/1)
*May 11 21:36:48.310: PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1)
entry
*May 11 21:36:48.310: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit)
Prune message for 239.1.1.1
*May 11 21:36:48.310: PIM(0): Adding register encap tunnel (Tunnel0) as for-
warding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:36:48.313: PIM(0): Received v2 Join/Prune on Ethernet0/1 from
192.168.43.4, to us
*May 11 21:36:48.313: PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit
set
*May 11 21:36:48.313: PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8,
239.1.1.1), Forward state, by PIM SG Join
At the FHR, the output of the debug ip pim message at this step is as follows:
Click here to view code image
*May 11 21:45:11.152: PIM(0): Check RP 192.168.0.2 into the (*, 239.1.1.1)
entry
*May 11 21:45:11.152: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit)
Prune message for 239.1.1.1
*May 11 21:45:11.152: PIM(0): Adding register encap tunnel (Tunnel0) as
forwarding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:45:11.155: PIM(0): Received v2 Join/Prune on Ethernet0/1 from
192.168.43.4, to us
*May 11 21:45:11.155: PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit
set
*May 11 21:45:11.155: PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8,
239.1.1.1), Forward state, by PIM SG Join
R3#
*May 11 21:45:15.133: PIM(0): Received v2 Register-Stop on Ethernet0/1 from
192.168.0.2
*May 11 21:45:15.133: PIM(0): for source 192.168.8.8, group 239.1.1.1
*May 11 21:45:15.133: PIM(0): Removing register encap tunnel (Tunnel0) as
forwarding interface of (192.168.8.8, 239.1.1.1).
*May 11 21:45:15.133: PIM(0): Clear Registering flag to 192.168.0.2 for
(192.168.8.8/32, 239.1.1.1)
R3 receives the register stop and the (S,G) join from the RP. Now the FHR (R3) sends the
multicast traffic towards the RP in a unicast tunnel. The flow of the multicast stream now progresses
from the RP down to R7 and ultimately towards the receiver. This is the initial tree build up in PIM
sparse-mode. For details on the SPT switch, refer to the earlier section, “The Rendezvous Point and
Shared Tree Dynamics .”
6. The multicast flow moves from the shared tree to a source tree: R3 received the prune
message from the RP and added the interface Ethernet0/1 to the OIL, as shown from the following
debug ip pim message, creating a source tree from the FHR to the LHR:
Click here to view code image
PIM(0): Received v2 Join/Prune on Ethernet0/1 from 192.168.43.4, to us
PIM(0): Join-list: (192.168.8.8/32, 239.1.1.1), S-bit set
PIM(0): Add Ethernet0/1/192.168.43.4 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM SG Join
R5 sees the source tree formed from the FHR (R3) and uses the RPF in the unicast routing table to
find a better metric. When this occurs, R5 sends a PIM prune toward the RP to remove itself from the
shared tree, as shown from the debug ip pim output from R5 below.
Click here to view code image
PIM(0): Received v2 Join/Prune on Ethernet0/0 from 192.168.75.7, to us
PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set, S-bit set
PIM(0): Add Ethernet0/0/192.168.75.7 to (*, 239.1.1.1), Forward state, by PIM
*G Join
PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for
239.1.1.1
PIM(0): Upstream mode for (*, 239.1.1.1) changed from 0 to 1
PIM(0): Insert (*,239.1.1.1) join in nbr 192.168.52.2's queue
PIM(0): Insert (192.168.8.8,239.1.1.1) sgr prune in nbr 192.168.52.2's queue
PIM(0): Update Ethernet0/0/192.168.75.7 to (192.168.8.8, 239.1.1.1), Forward
state, by PIM *G Join
PIM(0): Building Join/Prune packet for nbr 192.168.52.2
PIM(0): Adding v2 (192.168.0.2/32, 239.1.1.1), WC-bit, RPT-bit, S-bit Join
PIM(0): Adding v2 (192.168.8.8/32, 239.1.1.1), RPT-bit, S-bit Prune
PIM(0): Send v2 join/prune to 192.168.52.2 (Ethernet0/2)
Figure 3-19 shows the traffic flow for the new source tree.
 Figure 3-19 Source Tree Forwarding
7. The new source tree is fully activated : The source tree is now active, as seen using the show
ip mroute 239.1.1.1 command on R3:
Click here to view code image
R3#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
 N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:00:22/stopped, RP 192.168.0.2, flags: SPF
Incoming interface: Ethernet0/1, RPF nbr 192.168.43.4
Outgoing interface list: Null
(192.168.8.8, 239.1.1.1), 00:00:22/00:03:07, flags: FT
Incoming interface: Ethernet0/3, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 00:00:22/00:03:07
The shared tree has not been removed. When another receiver connected to a different router is
interested in the multicast stream, the shared tree and the same process of moving from a shared tree
to a source tree will occur again, like déjà vu all over again.
Note
While there is much going on under the hood in this section, the process of switching between the
shared tree and the source tree is relatively quick (less than a second in a robust network). This is
exactly what we want! If a sparse-mode network has trees stuck in the shared tree state, eating up RP
router resources, this indicates that a group has no source(s), or that something has likely gone wrong
in the PIM process. In fact, this is a common symptom that occurs in a network in which PIM
communication has broken down. For information on how to find and fix such failures, please see
Chapter 7 , which covers PIM troubleshooting.
Building the Multicast Routing Information Base
The unicast routing information base (RIB) has been populated by unicast routing protocols. It is
not necessary to build another multicast routing table with identical or additional route information
that consumes additional memory. As discussed earlier with RPF checks, rather than forward packets
to the source, multicast routers forward packets away from the source.
When a router receives a multicast packet, it performs the following actions.
1. Upon receipt of a multicast packet, the router checks the receiving interface to determine
whether it is in the path to the source (sending IP address) by performing a lookup in the RIB. This is
known as the RPF check .
2. If the interface is in the path to the source, the packet is forwarded.
3. If the receiving interface is not in the path to the source, the RPF fails and the packet is dropped.
Multicast takes a unique perspective when it comes to forwarding traffic in the network. Rather
than looking for the destination address of where to send the information as with traditional routing,
multicast routing does just the opposite. Because multicast routing is the opposite of unicast or
traditional routing, you can take advantage of the RIB.
The RIB is a collection of all routing information contained on a router and is a culmination of
connected routes, static routes, and routes learned from dynamic routing protocols. It also holds
adjacency information for neighboring routers. The RIB is used to populate the forwarding
information base (FIB) with the best path to a particular destination. The FIB table is used to forward
packets to the appropriate destination.
Multicast Routing Information Base and Multicast Forwarding Information Base
In the earlier section “Two Types of Trees ,” we addressed a couple of items that need some further
clarification. These are the multicast routing information base (MRIB) and multicast forwarding
information base (MFIB) and the way they interact with the other functions of the router.
The MRIB table is a collection of multicast entries, including source, group, group mask, and flags,
and may also contain a list of associated interfaces. The entries in the MRIB are created/updated by
the control plane when traffic is received from a connected source, a switchover occurs, or there is
some other data-driven event. The MRIB table (for non-local multicast groups) can be viewed on
older IOS platforms simply by using the show ip mroute command as it has been discussed. Newer
versions of IOS, including IOS XE, can display the MRIB table using the show ip mrib route
command, as demonstrated in Example 3-15 .
Example 3-15 Displaying the MRIB Table
Click here to view code image
ASR1K-2#show ip mrib route
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept, D - Drop
ET - Data Rate Exceeds Threshold,K - Keepalive,DDE - Data Driven Event
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, MD - mCAC Denied
(*,224.64.7.7) RPF nbr: 0.0.0.0 Flags: C
GigabitEthernet0/0/2 Flags: F NS
GigabitEthernet0/0/1 Flags: F NS
GigabitEthernet0/0/0 Flags: F NS
(192.168.8.10,224.64.7.7) RPF nbr: 192.168.32.3 Flags:
GigabitEthernet0/0/1 Flags: A
GigabitEthernet0/0/0 Flags: F NS
The MFIB is the multicast forwarding information derived from the MRIB and is presented as a
unique table, which displays how the router intends to forward multicast messages. Information such
as source, group, mask, counts, and rates of received, dropped, and forwarded packets are contained
in this table. Example 3-16 shows an abbreviated output from the show ip mfib command.
Example 3-16 MFIB State Table
Click here to view code image
ASR1K-2#show ip mfib
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signaling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(*,224.64.7.7) Flags: C HW
SW Forwarding: 0/0/0/0, Other: 0/0/0
HW Forwarding: 0/0/0/0, Other: 0/0/0
GigabitEthernet0/0/0 Flags: F NS
Pkts: 0/0
GigabitEthernet0/0/1 Flags: F NS
Pkts: 0/0
GigabitEthernet0/0/2 Flags: F NS
Pkts: 0/0
(192.168.8.10,224.64.7.7) Flags: HW
SW Forwarding: 0/0/0/0, Other: 15/2/13
HW Forwarding: 685830/156/1369/1673, Other: 1111/1111/0
GigabitEthernet0/0/1 Flags: A
GigabitEthernet0/0/0 Flags: F NS
Pkts: 0/0
Figure 3-20 depicts the interaction between the various components involved in the derivation of
multicast forwarding information.
 Figure 3-20 MFIB and MRIB
PIM-BiDir
RFC 5015 defines PIM-BiDir, which is a variant of protocol independent multicast (PIM). The
traffic in PIM-BiDir is rooted at the rendezvous point (RP) for the group and the IP address of the RP
acts as the key to having all routers establish a loop-free tree topology. Explicit join messages signal
membership to the bidirectional group. Traffic from sources is unconditionally sent up the shared tree
toward the RP and passed down the tree toward the receivers on each branch of the tree. This
unconditional forwarding of multicast traffic towards the RP using a prebuilt tree is one of the major
differences between PIM-BiDir and sparse-mode. The state is based on the prebuilt tree towards the
RP in the PIM domain. Therefore, the PIM-BiDir mode only supports a (*,G) group state. (S,G) state
is not seen in the mroute tables when using PIM-BiDir. Eliminating (S,G) state allows the PIM
domain to scale to an extensive number of sources. The pre-built tree used in PIM-BiDir enables it to
be used for many-to-many applications within individual PIM domains. Multicast groups in
bidirectional mode can scale to an arbitrary number of sources without incurring overhead due to the
number of sources.
PIM-BiDir is derived from the mechanisms of PIM sparse-mode (PIM-SM) and shares many
shortest path tree (SPT) operations. BiDir also uses unconditional forwarding of source traffic
toward the RP upstream on the shared tree, through the prebuilt state information; however, there is no
registration process for sources as in PIM-SM. This means the RP is used as a root point for the tree,
but not used as a tree transitioning platform, taking the tree management load off the RP altogether.
Figure 3-21 shows the simple forwarding of multicast traffic using a PIM-BiDir tree.

Figure 3-21 PIM-BiDir (*,G)

As you’ll notice in Figure 3-21 , the multicast stream forwarding to the downstream receiver is
similar to PIM sparse-mode. The only difference between PIM-BiDir and PIM sparse-mode is the
upstream communication and multicast stream flow to the RP. The reason the upstream flow is
different is because PIM sparse-mode requires an RPF check to pass through to avoid looping of
multicast data stream. The packet forwarding rules have been enhanced in PIM-BiDir over PIM-SM,
allowing the traffic to be forwarded directly to the RP. The multicast looping protection in PIM-BiDir
is provided by a designated forwarder (DF), which establishes a loop-free SPT rooted at the RP.
With PIM-BiDir, the RP address does not need to belong to the physical box; instead, it can be simply
a routable address. This is covered in more detail in Chapter 4 . The concept of the RPF interface is
important to understand with non-receiver segments, because the RPF interface is used in the (*,G) to
point towards the RP.
In a PIM-BiDir network, every segment (including point-to-point) elects a designated forwarder
(DF). The DF is elected based on the RP for a group. In a scenario of multiple RPs for different
groups, you will have multiple DFs. The DF router is responsible for creating a preexisting state that
is used in forwarding multicast packets towards the RP.
On every network segment and point-to-point link, all PIM routers participate in a procedure
called DF election . The procedure selects one router as the DF for every RP in bidirectional
multicast groups. This router is responsible for forwarding multicast packets received on that network
“upstream” to the RP. The DF election process is based on unicast metrics and uses highest IP
address in the case of a tie with the unicast metric. The DF forwards only one copy of the multicast
flow upstream. It should be noted that for every RP assigned to a separate multicast group, a new DF
is elected. A DF in PIM-BiDir takes the role of DR in PIM sparse-mode for first-hop router.
The conditions under which an update to the election process that creates state changes are:
Unicast routing table changes to reach the RP
Local interface changes the RPF
A new PIM router is seen in the topology
Neighbor failure that prompts a reelection
Figure 3-22 and the list that follows review the two-step process of building state for PIM-BiDir.
 Figure 3-22 PIM-BiDir Walkthrough 1
Step 1. Receiver joins the R4, which can be seen using the commands debug ip pim and show ip
mroute .
Click here to view code image
7: IGMP(0): MRT Add/Update Loopback0 for (*,239.1.1.1) by 4
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,239.1.1.1) by 4
*Nov 21 23:29:50.457: IGMP(0): Send v2 Report for 239.1.1.1 on
Loopback0
*Nov 21 23:29:50.457: IGMP(0): Received v2 Report on Loopback0 from
10.11.11.11 for 239.1.1.1
*Nov 21 23:29:50.457: IGMP(0): Received Group record for group
239.1.1.1, mode 2 from 10.11.11.11 for 0 sources
*Nov 21 23:29:50.457: IGMP(0): Updating EXCLUDE group timer for
239.1.1.1
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,239.1.1.1) by 0
*Nov 21 23:29:50.457: IGMP(0): MRT Add/Update Loopback0 for
(*,224.0.1.40) by 4
*Nov 21 23:29:50.457: IGMP(0): Send v2 Report for 224.0.1.40 on
Loopback0
*Nov 21 23:29:50.457: IGMP(0): Received v2 Report on Loopback0 from
10.11.11.11 for 224.0.1.40
*Nov 21 23:29:50.457: IGMP(0): Received Group record for group
224.0.1.40, mode 2 from 10.11.11.11 for 0 sources
R4#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
 Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:06:11/00:02:19, RP 10.99.99.99, flags: BCL
Bidir-Upstream: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:06:11/00:02:19
Ethernet1/0, Bidir-Upstream/Sparse, 00:06:11/stopped
The status at R2 is shown using the show ip mroute command.
Click here to view code image
R2#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:10:38/00:03:23, RP 10.99.99.99, flags: B
Bidir-Upstream: Ethernet1/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:10:38/00:03:23
Ethernet1/0, Bidir-Upstream/Sparse, 00:10:38/stopped
As you can see from this output, the state is built using the DF. The receiver sends the notification
upstream without registry (due to the prebuilt DF information) towards the RP. All the downstream
routers—in this topology, R2 and R4—have the state information for 239.1.1.1 learned via PIM-
BiDir. Also notice that the upstream interface Ethernet1/0 uses PIM-BiDir in the state table. The
downstream interface is Ethernet0/0 and uses PIM sparse-mode forwarding, as shown using the show
ip pim interface df command. The RP configuration needs to be done on each router. In Chapter 4 ,
you learn about various RP configurations for each PIM mode.
Click here to view code image
 R2# show ip pim interface df
* implies this system is the DF
Interface RP DF Winner Metric
Uptime
Ethernet0/0 10.99.99.99 *10.1.3.1 11
00:17:13
Ethernet1/0 10.99.99.99 0.0.0.0 11
00:00:00
Step 2. The source joins at R3 and the state at R3 is shown using the show ip mroute command:
Click here to view code image
R3#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*,224.0.0.0/4), 00:19:20/-, RP 10.99.99.99, flags: B
Bidir-Upstream: Ethernet1/0, RPF nbr: 10.1.1.1
Incoming interface list:
Ethernet0/0, Accepting/Sparse
Loopback0, Accepting/Sparse
Ethernet1/0, Accepting/Sparse
(*, 224.0.1.40), 00:20:15/00:02:53, RP 10.99.99.99, flags: BCL
Bidir-Upstream: Ethernet1/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:19:19/00:02:53
Loopback0, Forward/Sparse, 00:19:19/00:02:53
Ethernet1/0, Bidir-Upstream/Sparse, 00:19:20/stopped
 R3 will unconditionally forward multicast traffic toward the RP upstream using the shared tree.
There is no registering process for sources as in PIM-SM, the traffic is forwarded based on (*,G)
attributes between the source and receiver(s).
PIM-SSM
Source-specific multicast (SSM) is another flavor of PIM sparse-mode defined in RFC 3569. The
multicast stream is transmitted using an IP source and multicast address of a group. These two
attributes are the primary components necessary for the transportation of the multicast messages. This
protocol provides a host application with complete identification of a channel. Because this includes
a combination of the source IP address and the address of the group, there can be only one multicast
stream (without duplicate IP addresses in the network). Using SSM, you can have one source and
many multicast applications. The receiver must subscribe to the channel using IGMPv3. IGMPv3
provides the designated router with the source IP address and the multicast group address. This set of
addresses in IGMPv3 identifies the channel. The designated router connected to the receiver segment
already has the IP address of the source, and thereby the streams can directly be received from the
source. This mode of PIM does not require the use of an RP because the receiver is able to receive
the group from a specified source. In SSM and IGMPv3, there are no shared trees; consequently, the
router does not need to maintain (*,G) state. The multicast state only builds using SPTs (shortest path
trees) towards our sources.
Source-specific multicast (SSM) provides the capability to identify a set of multicast hosts not only
by group address but also by source. An SSM group, called a channel , is identified as an (S,G)
where S is the source address and G is the group address. An example for a channel is as follows:
Channel A (S,G) = (10.0.0.1, 232.1.1.1)
Channel B (S,G) = (10.0.0.2, 232.1.1.1)
Even though Channel A and B are represented using the same multicast group, 232.1.1.1, the
receiver can access a separate flow for Channel A because the identification of multicast stream is
based on the channel (the unicast address of the source and the multicast group address).
Chapter 1 covered the SSM addressing scheme. For this IANA has reserved the IPv4 address range
of 232.0.0.0/8, and it is recommended to allocate SSM multicast groups using that range. PIM-SSM
requires that the successful establishment of an (S,G) forwarding path from the source S to any
receiver(s) depends on hop-by-hop forwarding of the explicit join request from the receiver toward
the source. The receivers send an explicit join to the source because they have the source IP address
in their join message with the multicast address of the group. PIM-SSM leverages the unicast routing
topology to maintain the loop-free behavior. Traffic for one (S, G) channel consists of datagrams with
an IP unicast source address S and the multicast group address G as the IP destination address.
Systems receive this traffic by becoming members of the (S, G) channel. The receivers can receive
traffic only from designated (S, G) channels to which they are subscribed, which is in contrast to
ASM, where receivers need not know the IP addresses of sources from which they receive their
traffic.
IGMPv3 is a requirement for both the host and the next-hop device (router). If this support is not
available, then the option for host-to-network device communication at Layer 2 can be IGMP v3lite
and URL Rendezvous Directory (URD). These are two Cisco-developed transition solutions that
were designed to enable the immediate deployment of SSM services without the need to wait for the
availability of full IGMPv3 support on host operating systems. (Today, most host operating systems
include support for IGMPv3.) URD is a solution for content providers and content aggregators that
allows them to deploy receiver applications that are not yet SSM enabled (through support for
IGMPv3). IGMPv3, IGMPv3lite, and URD interoperate with each other, and can be used as
transitional solutions toward full IGMPv3 support for hosts.
IGMP and INCLUDE mode membership reports are used for channel subscription signaling with
IGMPv3. The INCLUDE can be statically created with IGMPv3lite or URD. The INCLUDE and
EXCLUDE mode of membership adds additional security not available in other PIM modes.
Note
The INCLUDE and EXCLUDE mode are additional filters that add extra security parameters to the
PIM control plane. In the INCLUDE mode, reception of packets is allowed for only those multicast
addresses specified in the source-list parameter. In the EXCLUDE mode, reception of packets is
allowed for all multicast addresses except those specified in the source-list parameter. The source
list is a list of IP source addresses from which multicast reception is allowed and is configured in the
form of an access control list (ACL).
The following examples explain the SSM process, beginning with Figure 3-23 :
 Figure 3-23 PIM SSM Single Channel A
Step 1. The receiver joins R4 using an IGMPv3 join message. The source IP is located off of R3.
Unicast routing is used to build state. Using the debug ip igmp and show ip mroute commands, you
can see the state information can on R1:
Click here to view code image
*Nov 21 23:01:24.899: IGMP(0): Updating expiration time on
(10.1.12.12,232.1.1.1) to 180 secs
*Nov 21 23:01:24.899: IGMP(0): Send v3 init Query on Loopback0
*Nov 21 23:01:24.899: IGMP(0): Set report delay to 0.7 seconds to
respond to General Query on Loopback0
*Nov 21 23:01:24.899: IGMP(0): Set report delay to 0.2 seconds to
respond to General Query on Loopback0
*Nov 21 23:01:25.132: IGMP(0): Building v3 Report on Loopback0
*Nov 21 23:01:25.132: IGMP(0): Add Group Record for 232.1.1.1, type 1
*Nov 21 23:01:25.132: IGMP(0): Add Source Record 10.1.12.12
*Nov 21 23:01:25.132: IGMP(0): Send v3 Report with 1 group records on
Loopback0
*Nov 21 23:01:25.132: IGMP(0): Received v3 Report for 1 group on
Loopback0 from 10.11.11.11
*Nov 21 23:01:25.132: IGMP(0): Received Group record for group
232.1.1.1, mode 1 from 10.11.11.11 for 1 sources
*Nov 21 23:01:25.132: IGMP(0): MRT Add/Update Loopback0 for
(10.1.12.12,232.1.1.1) by 0
*Nov 21 23:01:25.132: IGMP(0): Updating expiration time on
(10.1.12.12,232.1.1.1) to 180 secs
R4#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
 Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.4), 00:30:49/00:02:17, RP 0.0.0.0, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:30:49/00:02:17
(10.1.12.12, 232.1.1.1), 00:30:50/00:02:29, flags: sLTI
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Loopback0, Forward/Sparse, 00:01:33/00:02:29
(*, 224.0.1.40), 00:30:50/00:02:12, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:27:43/00:02:12
R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.12.12, 232.1.1.1), 00:05:41/00:02:43, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:05:41/00:02:43
(*, 224.0.1.40), 00:06:41/00:02:18, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
On R4, the IGMPv3 join is seen and the mroute table is updated. The “s” flag denotes the SSM
state. R1 shows the incoming interface as Ethernet0/0 and the outgoing interface as Ethernet1/0 for
232.1.1.1. The incoming interface is based on unicast table for 10.1.12.12, and the outgoing is based
on receiver reachability via the unicast routing table. When an additional subscription for the group is
processed by the network from a separate source (10.2.12.12) connected to R3, the SSM network
adjusts, adding the second channel. Figure 3-24 illustrates this dual-channel instantiation.

Figure 3-24 PIM SSM Dual Channel

Step 2. The show ip mroute command shows the dual channel for 232.1.1.1 with different source
IP addresses.
Click here to view code image
R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
 U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
…
(10.1.12.12, 232.1.1.1), 00:16:31/00:02:42, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.10.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:16:31/00:02:42
(10.2.12.12, 232.1.1.1), 00:17:30/00:02:39, flags: sLTI
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse, 00:00:20/00:02:39
….
R1 has no state without the source IP address available in the routing table for 10.2.12.12,
232.1.1.1). This is shown using the show ip mroute command:
Click here to view code image
R1# show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p -
PIM Join
 Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.12.12, 232.1.1.1), 00:19:04/00:03:09, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:19:04/00:03:09
(*, 224.0.1.40), 00:20:04/00:02:01, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
Step 3. The source is active and available as seen in the unicast RIB. The state table on R1
changes with the state of (10.2.12.12, 232.1.1.1) seen in the routing table. These are viewed using the
debug ip pim and show ip mroute commands:
Click here to view code image
*Nov 21 22:55:59.582: PIM(0): Insert (10.2.12.12,232.1.1.1) join in nbr
10.1.1.2's queue
*Nov 21 22:55:59.582: PIM(0): Building Join/Prune packet for nbr
10.1.1.2
*Nov 21 22:55:59.582: PIM(0): Adding v2 (10.2.12.12/32, 232.1.1.1),
S-bit Join
*Nov 21 22:55:59.582: PIM(0): Send v2 join/prune to 10.1.1.2
(Ethernet0/0)
R1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.2.12.12, 232.1.1.1), 00:03:38/00:02:33, flags: sT
 Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:03:38/00:02:33
(10.1.12.12, 232.1.1.1), 00:25:29/00:02:38, flags: sT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.2
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:25:29/00:02:38
(*, 224.0.1.40), 00:26:28/00:02:31, RP 0.0.0.0, flags: DPL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
For the same multicast group, two channels are shown in the output.
Step 4. The unicast routing table changes on R2, a new link is added, and the connection between
R1 and R3 is brought down. Prior to the change, the mroute state on R2 is shown using the show ip
mroute command:
Click here to view code image
R2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
..
(10.1.12.12, 232.1.1.1), 00:37:33/00:03:19, flags: sT
Incoming interface: Ethernet1/0, RPF nbr 10.1.10.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:09:15/00:03:19
..
 The mroute state snapshot for (10.1.12.12, 232.1.1.1) shows the incoming interface of Ehternet1/0,
which connects R1 to R3. Figure 3-25 shows the topology change.

Figure 3-25 PIM SSM Dual Channel After Topology Change

At R2, the topology change can be seen using the show ip mroute 232.1.1.1 command:
Click here to view code image
R2#show ip mroute 232.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
 N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.1.12.12, 232.1.1.1), 00:42:23/00:03:28, flags: sT
Incoming interface: Ethernet3/0, RPF nbr 10.1.9.2
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:00:01/00:03:28
(10.2.12.12, 232.1.1.1), 00:43:23/00:02:55, flags: sLTI
Incoming interface: Ethernet3/0, RPF nbr 10.1.9.2
Outgoing interface list:
Loopback0, Forward/Sparse, 00:26:12/00:02:55
The incoming interface is Ethernet3/0.
IGMPv3 subscribes the receiver to the specific source IP address in the join message. This greatly
simplifies the tree build-up process, using an explicit source tree from the source to the receiver in
SSM, and it leverages existing unicast routing information for multicast forwarding. This completely
eliminates the need for an RP in the network while ensuring a loop-free forwarding topology.
Summary
Multicast networks consist of senders, receivers, and the network infrastructure. The
communication of multicast messages uses the concept of a tree . The sender is the root of the tree and
the receiver is a leaf , with the network being the branches or infrastructure . The responsibility of
the infrastructure is to eliminate any duplication of messages, consequently removing any loops. This
process is known as building the tree . Trees are built using one of two methods: a shared-tree shown
as an (*,G) or a source-tree shown as an (S,G). A shared-tree is rooted at the rendezvous point (RP),
and a source-tree is rooted at the source (S,G) or sender.
Layer 3 networking devices discover other directly attached networking devices and establish a
“neighbor” relationship. Neighbor information is exchanged, which aids in understanding the
capability of each device and in minimizing multicast joins from the same segment.
Protocol independent multicast (PIM) uses the underlying unicast routing protocol to forward
multicast messages. Because multicast routing is the opposite of unicast routing, in that it sends
messages away from the source, a new routing table for multicast specific routes is not required.
Multicast routing uses the concept of reverse path forwarding (RPF).
Forwarding of multicast messages can operate in the following modes: dense, sparse, and sparse-
dense. Dense mode uses a push model, in which multicast messages are sent to every PIM-enabled
device in the network. By contrast, sparse mode uses a pull model , in which receivers request
multicast messages. Finally, sparse-dense mode uses dense-mode flooding to propagate RP
information and sparse-mode for sending messages. Be aware that a failure of the RP in a sparse-
dense mode environment can cause dense-mode flooding.
 Internet Group Management Protocol (IGMP) is the most common mechanism to control multicast
messages at Layer 2. There are currently three versions of IGMP. IGMPv3 is the latest, and it does
not require the use of an RP because it has awareness of the multicast source.
Any-source multicast (ASM) uses both a shared-tree and a source-tree. Typically, multicast
messages start from a shared-tree using a RP but switch to a source-tree to provide better network
efficiency. Bidirectional PIM (BiDir) is generally used to many-to-many communication and it
supports only shared-trees. Source-specific multicast (SSM) requires receivers to be IGMPv3-
aware, because this method uses only source-trees.
Chapter 4. Protocol Independent Multicast
Chapter 4. Protocol Independent Multicast
Chapter 3 , “IP Multicast at Layer 3 ,” addressed the different protocol independent multicast
(PIM) modes and how those modes affected the growing or building of multicast trees. You saw the
significant role that the rendezvous point (RP) played in establishing PIM sparse-mode and BiDir
trees. In addition, you learned that source-specific multicast (SSM) does not require the use of an RP.
This chapter covers the RP design mechanisms and configuration nuances using various Cisco
platforms.
RP Overview
PIM-SM uses shared trees. With shared trees, multicast distribution is rooted at the RP. The
process of building a shared tree requires that the network components register active sources as well
as receivers for a given multicast group to the RP. To register to the RP, routers must encapsulate data
in PIM control messages and send it by unicast to the RP. The source’s upstream designated router
(DR) encapsulates and sends the register packet. Remember, the DR is a router on the source’s local
network. A single DR is elected from all PIM routers on a subnet so that unnecessary control
messages are not sent.
It should be noted that any number of routers could be configured as an RP for a given multicast
group range. When the RP is configured, this information must be available to downstream Layer 3
devices on the network so that a shared tree for a specific group can be established. In simple sparse-
mode deployments, all multicast groups are mapped to a single RP. Figure 4-1 provides an example
of the RP concept using a shared tree.

Figure 4-1 Rendezvous Point in a Shared Tree

In this example, router R1 is defined as the RP for multicast group 239.1.1.1. The other routers in
the diagram are called the downstream routers . Each of the downstream routers needs to know about
the RP. The RP information contains details about the IP address the RP is using (the location of the
RP) and the group addresses for which the RP will require registration. It is imperative that the router
acting as RP and the downstream routers all agree whom the RP is for a given group.
The downstream routers use this information to create mappings of groups to a given RP address.
This mapping is not necessarily one-to-one; there might be many RPs for different groups, or there
might be only one RP for all groups. The number and placement of RPs is an administrative decision
that is usually based on network scale and other best practices.
The RP-to-group mapping is a critical step in building sparse mode trees. If there is no group
mapping, DRs will not be able to register group subscriptions, active sources cannot be tracked, and
routers downstream will not know the direction in which to RPF check shared tree entries. In short,
the shared tree will not form across the network, from the RP to the receivers, and the multicast path
will fail.
Examining the following show command output from an IOS router can give us additional insight
into how routers use this information:
Click here to view code image
R1#show ip pim rp 239.127.1.1
Group: 239.127.1.1, RP: 192.168.0.2, v2, v1, uptime 05:44:08, expires 00:02:53
Using the show ip pim rp address command, you see that the configured RP for multicast group
239.127.1.1 is the router with an interface using 192.168.0.2, but this only tells you what RP address
the router is aware of for group 238.127.1.1. Using the show ip pim rp mapping command shows all
the mappings learned by the router, even those that have been learned dynamically but are not
installed. Adding the in-use option shows only those mappings that are installed in the mRIB and how
the mapping was learned. Example 4-1 shows that all multicast groups are mapped to RP
192.168.0.2, and the mapping was learned dynamically through Auto-RP, a Cisco proprietary RP
information distribution protocol.
Example 4-1 show ip pim rp mapping in-use Command Output
Click here to view code image
R1#show ip pim rp mapping in-use
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.168.0.2 (?), v2v1
Info source: 192.168.0.2 (?), elected via Auto-RP
Uptime: 05:44:19, expires: 00:02:42
Dynamic (Auto-RP or BSR) RPs in cache that are in use:
Group(s): 224.0.0.0/4, RP: 192.168.0.2, expires: 00:00:58
Adding a group address to the show ip pim rp mapping command provides the mapping
information for that specific group; in the case of Example 4-2 , the mapping is using static ACL 10.
Example 4-2 show ip pim rp mapping group-address Command Output
Click here to view code image
R1#show ip pim rp mapping 239.127.1.1
PIM Group-to-RP Mappings
Acl: 10, Static-Override
RP: 192.168.0.2 (?)
This output clearly shows that group-to-RP mappings can be learned by the router through various
methods. This brings us to the concept of propagating the RP information to the downstream devices.
Any inconsistencies in RP group mappings by downstream routers also cause trees to fail because
downstream routers will not have the appropriate RPF or other information from which to build a
share tree.
The downstream devices can learn this RP information in one of two ways: static mapping through
manual configuration, or dynamic sharing and mapping through protocols. A network administrator
has two protocol options for dynamic distribution: Auto-RP (Cisco proprietary) or the IETF standard
bootstrap router (BSR). These RP propagation methods are considered at length in later sections of
this chapter.
Similar to other IP protocols, reliability and availability are very important in any network,
especially if forwarding information is being propagated dynamically. Networks often address
availability, frequently called high availability (HA) , through redundancy of critical systems. IP
multicast networks are similar in function and RPs can be configured with HA in mind.
Figure 4-2 shows a network with HA added to the RP configuration. RP redundancy provides high
availability to RP resources using shared trees. High availability in networking terms can usually be
classified as active/active or active/standby. The same is true for RP redundancy configurations.

Figure 4-2 RP High Availability

IP Multicast Domains
In order to create effective multicast designs, we need to understand the meaning and use of a
multicast domain. Just like the unicast routing protocols OSPF and EIGRP, PIM routers have the
capability to dynamically share information about multicast trees. For most networks, there is only
one routing protocol that is used internally, the interior gateway protocol, or IGP.
When the IGP network is properly designed, most routers in the network will have the same routes
in their individual routing information base (RIB). The routes may be summarized into larger entries
on some routers, even as far as having only one summary (default) route on stub routers. Often, this
process is controlled by the use of regions (or areas, in the case of IS-IS or OSPF). The point is that
when it’s configured, the IGP dynamically provides the necessary routing information to all of the
routers that need the information, and those routers interacting with each other are part of a domain.
Of course, the deployed IGP has a natural, physical boundary. When the interface of an IGP router
is not configured to send/receive IGP information, that interface bounds the IGP. This serves the
purpose of preventing internal routing information from leaking to routers that should not or do not
need internal information.
To share routes outside the network, administrators generally use an External Gateway Protocol
(EGP). If a network needs to connect to the global Internet, it will generally use Border Gateway
Protocol (BGP) as the EGP. The EGP only shares essential IGP routes with external routers, so that
only internal networks meant for public access are reachable by external devices. The routing process
of the IGP is kept separate and secure from external influence. For most networks, the natural
boundary of the internal routing domain lies between the IGP and the EGP of the network.
We often call the internal network, as it appears to the outside, an autonomous system (AS) . In
fact, BGP relies heavily on this concept because each public BGP network must use an assigned AS
number (ASN) to participate in the global Internet. As with IP address and multicast IP group
assignments, IANA assigns these ASNs to participating networks. To more deeply understand the
division of networks into domains and autonomous systems, please refer to IETF RFCs 1136 and
1930.
Multicast networks also must have boundaries; however, the boundaries may be drastically
different than those of the underlying unicast network. Why? It is important to remember that IP
multicast networks are an overlay on the IGP network, and the network routers can only have one PIM
process.
The unicast network could use multiple routing processes or even protocols through the use of
redistribution. Sophisticated link-state protocols, like OSPF and IS-IS, provide built-in mechanisms
for tighter controls on route sharing. PIM routers can share tree state information with any PIM
neighbors and have no similar structures.
Under the definition of a domain, all PIM routers with the capability to share trees could be
considered a part of the domain. Although convenient for the purposes of multicast forwarding, it may
not be secure or desirable to have all multicast sources and groups available to all routers within that
domain. It also may not be entirely efficient, depending on the location of sources, receivers, and
RPs. PIM networks need tighter, more configurable boundaries and a different definition for a
domain.
Network architects can define and create PIM domains in multiple ways. If the multicast overlay is
very simple, then the domain may also be very simple. The domain could span an entire IGP network,
with universal PIM neighbor relationships between all IGP routers. When required, a single RP could
be used for all group mappings. In this type of domain, all multicast groups and sources would be
available to all systems within the domain.
If the network requirements are more stringent, it is likely that a defined tiered domain model will
be needed. Many network architects use group access requirements as a way to define a multicast
domain. Let’s look at a theoretical example, in this case, Multicaster’s Bank Corporation.
Figure 4-3 shows the Multicaster’s global network. It is very likely, especially in a financial
institution, that applications will require intense security between various portions of the network.
For example, there might be a financial trading application that must update several local servers in
real time. The security and accuracy of such information is of paramount concern. Thus, the network
architect may want to define a single domain around that application.
 Figure 4-3 Multicaster’s Bank Corp
In the case of Multicaster’s there are two data centers at each of the two major trading locations,
L.A. and N.Y. Each data center must process only the local trading information and should not share
multicast data flows between them. A domain with secure boundaries must then be configured for
each data center.
Multicaster’s Bank Corp. system administrators also prefer to use multicast groups for local
administrative tasks, or for local services like music on hold for local IP telephony systems. It would
not be very secure or prudent to allow the local administrator’s multicast flows to interrupt or
possibly corrupt the flows updating the trade floor application in the L.A. data center.
One effective way to divide these two types of flows into separate domains is to simply use sparse
mode on all router links but to use a unique RP for each domain. With different RP structures, the
routers in each domain will build trees only within that domain. Figure 4-4 takes a closer look at the
L.A. location using such a model.
 Figure 4-4 Multicaster’s L.A. Multicast Domains
As discussed earlier, an RP is quantified and mapped for specific multicast groups. This multicast
group presence with the mapped RP is called a multicast scope range, and that scope becomes the
domain, the boundaries being any routers in the PIM network not configured with the RP information
for a given group. In enterprise designs, you can have multiple scopes specific to a group. These
scope ranges are aligned with RP and PIM domains. Scope ranges can superimpose over each other
or be a subset of one another. Figure 4-5 illustrates a scope range.
 Figure 4-5 Scope Range
The scope of the domain is dependent on the capability of the downstream routers to properly map
group addresses to the appropriate RP. In order to build shared trees and subsequent source trees,
each router in the domain must map group addresses to the same RP for a given group in that domain.
As mentioned previously, if this group mapping is not consistent, or present, tree formation cannot be
completed and flows will fail.
The configuration items and criteria reviewed here, especially RP propagation, availability, and
scoping, are important to consider while learning dynamic RP protocols. Scoped multicast domains
play a very important role in multicast design. Multicast domains and the relationships between them
will be discussed in greater detail in Chapter 5 .
Basic PIM Configuration
The PIM process begins when two or more routers establish a PIM neighbor adjacency on a given
segment. To begin the adjacency process, any interfaces participating in multicast routing must be
configured for PIM communications. To configure an IOS router interface for PIM, use the following
interface level command:
Click here to view code image
ip pim { dense-mode [ proxy-register {list access-list | route-map map-name} ]
| passive | sparse-mode | sparse-dense-mode }
In IOS-XE and in NX-OS, the ip pim command is entered at the interface configuration mode. For
IOS-XR, the command is entered as router pim , which enables PIM for the default context and enters
the PIM configuration submode. The passive command option prevents the sending of PIM messages
from this interface and instead duplicates and forwards any IGMP reports received.
Note
 Don’t forget the importance of the underlying unicast network. Because of the heavy reliance on
unicast, it is wise and recommended to simply include every interface in the domain in the PIM
topology. That means configuring PIM on every IP interface within the domain. As the domain, or the
network grows, you can simply make the PIM configuration a network standard. There might be cases
where this does not make sense; see Chapter 5 for more details.
Note
The dense-mode proxy register command option allows a dense-mode router to use a designated
router to join a sparse-mode domain. The DR elected can generate and send a (*,G) register messages
from the (S,G) dense-mode trees in the routers mRIB. This allows for full multicast domain
participation where legacy routers cannot support sparse mode. The administrator can also assign a
route map or access list to limit the groups allowed by the proxy.
Because dense-mode PIM is no longer a recommended mode for multicast networks, it is likely
that most networks will be running in sparse-mode. In a sparse-mode deployment, it is not enough to
have neighbor adjacencies. We also need an RP and a way to associate the group to RP mapping. As
previously mentioned, RPs and group mappings can be learned statically (through manual
configuration) at each router or dynamically (by using either the Auto-RP or BSR protocols for
propagation).
Static RP
Enabling PIM sparse-mode using a static RP is perhaps the simplest way to configure a multicast
domain. A static RP is defined through manual configuration on the RP itself and at every downstream
router. The configuration, with multicast scoping (that is, multicast RP configuration with an access-
list for multicast group definition), has to be defined at every downstream router in exactly the same
way; otherwise, the domain will be incomplete.
Using a static RP might be a good choice for certain multicast configurations, including Anycast RP
with MSDP for RP redundancy. This can also be an attractive option if the network is small. This RP
mechanism does not provide any redundancy (unless coupled with Anycast RP). Anycast RP is
discussed more fully in subsequent sections of this chapter.
Use the commands in Table 4-1 , shown by platform, to configure a static RP.

Table 4-1 Commands to Configure a Static RP

A static RP can coexist with dynamic RP mechanisms such as Auto-RP. By default, dynamically
learned RP mappings take precedence over manually configured RPs. Thus, if a router receives Auto-
RP information for a multicast group that has been manually configured, the Auto-RP information will
be used unless the override keyword is specified. This scenario occurs only if there are multiple RPs
available for mapping to the same group(s).
 Let’s look at a basic configuration example using only one static RP for all multicast group
addresses. Figure 4-6 shows the network diagram for this configuration.

Figure 4-6 Static RP. The Icons Represent Layer 3 Functionality, Including IOS, IOS-XR, and
NxOS
The following are step-by-step configuration instructions to enable PIM sparse-mode for IOS, IOS-
XR and NX-OS using static RP.
The steps to configure static RP with IOS and enabling PIM sparse-mode are as follows:
Step 1. Enable IP multicast routing.
ip multicast-routing
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with the ip pim sparse-
mode command:
Click here to view code image
interface Loopback0
ip address 192.168.0.1 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.12.1 255.255.255.0
ip pim sparse-mode
Step 3. Add the static RP configuration:
Click here to view code image
R3(config)#ip pim rp-address 192.168.0.1 ?
<1-99> Access-list reference for group
<1300-1999> Access-list reference for group (expanded range)
WORD IP Named Standard Access list
override Overrides dynamically learnt RP mappings
Configuring IOS-XR is significantly different from configuring IOS. The PIM configuration is
accomplished through separate multicast-routing and router pim configuration modes. The
following basic steps explain how to configure PIM using a static RP with PIM sparse-mode in IOS
XR:
Step 1. Enable multicast-routing and enable Layer 3 interfaces:
 Click here to view code image
multicast-routing
address-family ipv4
interface Loopback0
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
!
interface all enable
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with the ip pim sparse-
mode command:
Click here to view code image
router pim
address-family ipv4
interface Loopback0
!
interface GigabitEthernet0/0/0/0
!
interface GigabitEthernet0/0/0/1
Step 3. Add the static RP configuration:
Click here to view code image
RP/0/0/CPU0:R1(config-pim)#router pim
RP/0/0/CPU0:R1(config-pim)#address-family ipv4
RP/0/0/CPU0:R1(config-pim-default-ipv4)#rp-address 192.168.0.1?
WORD Access list of groups that should map to given RP
bidir Specify keyword bidir to configure a bidir RP
override Static RP config overrides auto-rp and BSR
<cr>
The static RP configuration in NX-OS is similar to IOS and IOS-XE configurations and is as
follows:
Step 1. Enable the feature pim .
feature pim
Step 2. Enable interfaces in the Layer 3 domain, including the loopback with ip pim sparse-mode :
Click here to view code image
interface Ethernet2/1
no switchport
mac-address 0001.4200.0001
ip address 192.168.23.1/24
ip router ospf 1 area 0.0.0.0
ip pim sparse-mode
no shutdown
Step 3. Add the static RP configuration:
Click here to view code image
nexusr1(config)# ip pim rp-address 192.168.0.1 ?
<CR>
bidir Group range is treated in PIM bidirectional mode
group-list Group range for static RP
override RP address will override the dynamically learnt RPs
prefix-list Prefix List policy for static RP
route-map Route Map policy for static RP
Note
Why is it important to configure the main network loopback interface with sparse-mode PIM as
shown in the preceding examples? After all, the loopback interface is unlikely to have any PIM
neighbors. This is a recommended practice for any multicast overlay. The reason for this
recommendation is that the router can then fully participate in the multicast domain, even if errors are
occurring on leaf facing interfaces. It also allows the loopback interfaces to be used as a RP
addresses or mapping agents in dynamic RP propagation, making them more reliable. See Chapter 5 ,
“IP Multicast Design Considerations and Implementation ,” for more information on this and other
best practices for multicast networks.
PIM Dense Mode
To configure dense mode on older Cisco IOS routers and switches, use the following commands:
Click here to view code image
C6K-720(config)#ip multicast-routing [vrf vrf-name] [distributed]
C6K-720(config)#interface {type [number|slot/port[/port]]}
C6K-720(config-if)#ip pim dense-mode [proxy-register {list access-list |
route-map map-name}]
Figure 4-7 depicts a small campus network with a very limited multicast deployment for minor host
updates. The underlying configuration example enables PIM dense-mode multicast and utilizes IGMP
snooping for improved Layer 2 efficiency. IGMP snooping should be enabled by default.
 Figure 4-7 Small Dense-Mode Deployment
Note
As discussed previously, there are very few reasons to ever deploy a PIM-DM network. Because
of this, many Cisco networking operating systems will not support dense-mode configuration or
certain dense-mode features. At presstime, Cisco IOS-XR and NX-OS do not support any PIM dense-
mode–deployment or configurations. The following sample configuration is only provided as
supplemental for existing dense-mode–compatible systems.
Using the network topology in Figure 4-7 , the IOS configuration commands in Example 4-3
demonstrate how to configure dense-mode multicast.
Example 4-3 Configuring Dense-Mode Multicast in IOS
Click here to view code image
CR1(config)#ip multicast routing
CR1(config)#interface vlan 10
CR1(config-if)#ip pim dense-mode
CR2(config)#ip multicast routing
CR2(config)#interface vlan 10
CR2(config-if)#ip pim dense-mode
 Dynamic RP Information Propagation
There are two ways to dynamically propagate RP information to routers within a domain:
Auto-RP (Cisco proprietary)
Bootstrap router (BSR)
Both solutions are acceptable because they provide a similar service and play a key role in a
multicast design.
You may be asking yourself, “If static configurations work well, why have a dynamic protocol at
all?” As discussed earlier, one of the most important concepts in group mapping is that all routers
within a domain agree on the RP for a given group. If a network is very large, has many overlapping
domains, many multicast applications, many rendezvous points, or all of the above, a consistent group
mapping through static commands may become extremely difficult to manage. In fact, it is for this
reason that these two dynamic protocols provide not only dynamic propagation, but also methods of
ensuring RP mapping accuracy and consistency throughout a domain at all downstream routers.
Remember, the RP itself does not make mapping decisions for downstream routers. Each router must
learn of the RP individually and use the provided information to determine the best RP to map a group
to. There are some similarities between Auto-RP and BSR that provide this consistency to
downstream routers.
The control for this process is accomplished through the concept of centralized mapping. This
means that some routers in the network are configured as RP routers and advertise themselves as such
to other routers in the network. Centralized mapping routers receive the information about the RPs
available within the network and establish group to RP mapping parameters, or compile available RP
sets. When RP information is distributed from the centralized mapping routers, downstream routers
need only listen to these advertisements and use the advertised information to create local RP
mapping entries. This also serves the added purpose of limiting the number of protocol messages
required throughout the domain.
Auto-RP and BSR both perform these mapping and advertising functions differently. But in the end,
they provide the same essential functions to the network.
Auto RP
Auto-RP provides HA (active/standby) to the RP service. The propagation of RP information to the
downstream routers is done via Auto-RP messages. The downstream routers do not require an
explicit RP configuration. Rendezvous points using Auto-RP announce their availability to the
mapping agents via the 224.0.1.39 multicast group. The RP mapping agent listens to the announced
packets from the RPs, then sends RP-to-group mappings in a discovery message to 224.0.1.40.
Downstream routers listen for mapping advertisements on group 224.0.1.40 and install the RP
mappings as advertised from the mapping agent. It is acceptable to use the same interface address RP
as a candidate and mapping agent. In larger systems to provide greater scalability, it would more
efficient to use different interfaces, or to separate the candidate and agent functions to different
routers. Figure 4-8 shows the Auto-RP mechanism.
 Figure 4-8 Auto-RP Overview
The two multicast groups for Auto-RP information are advertised via dense mode in the sparse-
dense mode of interface operation. This flooding of message allows automatic propagation to the
downstream routers. As mentioned earlier, some operating systems do not support dense mode. How
can RP information be propagated in a sparse-mode–only environment? You can use “listen”
configuration commands in global configuration mode to cause IP multicast traffic for the two Auto-
RP groups of 224.0.1.39 and 224.0.1.40 to be protocol independent multicast (PIM) dense-mode
flooded across interfaces operating in PIM sparse-mode.
The Auto-RP mapping agent uses the following logic to build the RP-cache:
When there is a tie between two candidate RPs, the RP with the highest IP address wins the tie.
Two candidate RPs contest where one group is a subset of another, but the RPs are different. Both
will be sent in the discovery RP-cache.
Auto-RP is best-suited in a multicast scoped environment. The Auto-RP message has an inbuilt
time to live (TTL) and various other boundary features that make it best-suited in scoped multicast
environments. A scoped multicast domain has its own RP with a group address assigned, which
makes it a separate PIM domain.
Table 4-2 outlines some items to remember using Auto-RP:
Table 4-2 Auto-RP Feature Considerations
Table 4-3 outlines the IOS/XE, IOS XR, and NX-OS mapping agent commands.

Table 4-3 Mapping Agent Commands for IOS/XE, IOS XR, and NX-OS
Table 4-4 outlines the IOS/XE, IOS XR, and NX-OS Candidate RP commands.

Table 4-4 Candidate RP Commands for IOS/XE, IOS XR, and NX-OS
Table 4-5 outlines the IOS/XE, IOS XR, and NX-OS Auto-RP Listener commands.

Table 4-5 Auto-RP Listener Commands for IOS/XE, IOS XR, and NX-OS
Note
With NX-OS, use the listen keyword to process the Auto-RP message and use the forward
keyword to send the Auto-RP message to next-downstream routers.
Figures 4-9 through 4-11 illustrate a typical deployment example on how to configure Auto-RP in
IOS, IOS-XR and NX-OS. In this example, R1 and R2 are the candidate RPs and mapping agents, a
common deployment practice.

Figure 4-9 IOS RP Configuration Topology

Sample Configuration: Auto-RP for IOS
Example 4-4 shows the RP configuration for Router R1 and R2.
Example 4-4 Configuring RP for R1 and R2 in IOS
 Example 4-5 shows the downstream router configuration:
Example 4-5 Configuring the Downstream Router in IOS
Click here to view code image
R3: Downstream router
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.3 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
 ip address 192.168.12.3 255.255.255.0
ip pim sparse-mode
!
!
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
!
Sample Configuration: Auto-RP for IOS-XR
Figure 4-10 shows the topology for the following sample configuration of Auto-RP for IOS-XR.

Figure 4-10 IOS-XR Auto RP Configuration Topology

Example 4-6 shows the RP configuration for Router R1 and R2.
Example 4-6 Configuring RP for R1 and R2 in IOS-XR
 Example 4-7 shows the downstream router configuration.
Example 4-7 Configuring the Downstream Router in IOS
Click here to view code image
R3 : Downstream router
hostname R3
!
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
Sample Configuration: Auto-RP for NX-OS
Figure 4-11 shows the topology for the following sample configuration of Auto-RP for NX-OS.

Figure 4-11 NX-OS Auto-RP Configuration Topology

Sample configuration—Auto-RP for NX-OS:
Example 4-8 shows the RP configuration for Router R1 and R2.
Example 4-8 Configuring RP for R1 and R2 in NX-OS
 Example 4-9 shows the downstream router configuration.
Example 4-9 Configuring the Downstream Router in IOS
Click here to view code image
R3 : Downstream router
hostname R3
!
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
!
BSR
BSR is an open standards protocol defined by the IETF. BSR is another RP high-availability
mechanism that provides active/standby functionality and automatic downstream RP information
propagation. The candidate RP in the BSR domain advertises its availability by sending RP cache
information to all the downstream routers in the PIM domain. The function of the BSR is to collect
and broadcast the RP set to all routers in the domain. The RP cache information is sent to all
downstream routers using PIMv2 message group (224.0.0.13) hop-by-hop to all routers in the PIM
domain. As Figure 4-12 shows, the candidate RP sends its availability as RP only to the BSR router.

Figure 4-12 BSR Overview

The bootstrap message sent by the BSR includes information about all the candidate-RPs. Each
router uses a common algorithm to select the same RP address for a given multicast group. The
selection criterion for the RP is based on the common algorithm and is the responsibility of each
downstream router. This is one of the major differences between BSR and Auto-RP. Downstream
routers use the following criteria to select the RP in BSR:
Multicast group range: Reviews the group that is attached to the RP for the selection.
RP priority: Configured field on the candidate RP, the higher priority wins the RP selection
process for a specific group.
Hash Mask: Hash-mask-length bits of the group IP address are used to calculate the hash value.
It uses a selection procedure for the whole multicast address space advertised in the RP multicast
group. This multicast group is partitioned among different RPs. Every RP gets approximately 2^[32-
hash-mask-length] groups assigned, provided that there are enough RPs to evenly distribute the load.
This does not offer active/active within a group range. It does however, provide address that use RP-
1 within the multicast range based on the hashed value and addresses that use RP-2. The BSR
mechanism is a nonproprietary method of defining RPs that can be used with third-party routers.
Similar to Auto-RP, there is no configuration necessary on downstream router for BSR (except on
candidate-BSRs and candidate-RPs).
BSR is a standards-based protocol available with PIMv2. Unlike Auto-RP, BSR does not use any
dense-mode groups to flood candidate RP and RP mapping information. BSR uses PIM messages on a
hop-by-hop basis with all messages flooded using the all-PIM routers group with TTL of 1. This
keeps those multicast advertisements to a local subnet.
Table 4-6 outlines the IOS/XE, IOS XR, and NX-OS commands for configuring the BSR.

Table 4-6 BSR Configuration Commands for IOS/XE, IOS XR, and NX-OS
Table 4-7 outlines the IOS/XE, IOS XR, and NX-OS commands for configuring the BSR candidate
RP.

Table 4-7 Candidate RP Configuration Commands for IOS/XE, IOS XR, and NX-OS
Figures 4-13 through 4-15 illustrate a typical deployment example on how to configure BSR in
IOS, IOS-XR and NX-OS. In this example, R1 and R2 are the candidate RPs and BSR routers, a
common deployment practice.
Sample Configuration: BSR in IOS
Figure 4-13 shows the topology for the following sample configuration of BSR in IOS.
 Figure 4-13 IOS BSR Configuration Topology
Example 4-10 shows the BSR RP configuration for Router R1 and R2.
Example 4-10 Configuring BSR RP for R1 and R2 in IOS

Note
Remember, because BSR uses the local PIM multicast group (224.0.0.13) no additional
configuration is required for downstream routers to process BSR updates. The downstream router
will receive the BSR mapping advertisements, process the update, and update any group mappings as
necessary. Multicast group state entries will, of course, use the RP(s) in the mapping as processed.
Sample Configuration: BSR in IOS-XR
Figure 4-14 shows the topology for the following sample configuration of BSR in IOS-XR.

Figure 4-14 IOS-XR BSR Configuration Topology

Example 4-11 shows the BSR RP configuration for Router R1 and R2.
Example 4-11 Configuring BSR RP for R1 and R2 in IOS-XR
Sample Configuration: BSR in NX-OS
Figure 4-15 shows the topology for the following sample configuration of BSR in NX-OS.

Figure 4-15 NX-OS BSR Configuration Topology

Example 4-12 shows the BSR RP configuration for Router R1 and R2.
Example 4-12 Configuring BSR RP for R1 and R2 in NX-OS
 Note
It is important to note that because of the differences between mapping process used by BSR and
Auto-RP the two protocols should never be used simultaneously in the same network or PIM domain.
Anycast RP
Anycast RP uses a load-balancing technique that achieves active/active RP distribution for a
multicast group. Figure 4-16 illustrates the mechanics of active/active RP distribution using Anycast
techniques.
 Figure 4-16 Anycast RP Overview
There are two variants of Anycast RP you should be aware of.
RFC 3446 based on Multicast Source Discovery Protocol (MSDP) to maintain the active state
between the RPs.
RFC 4610 based on protocol independent multicast (PIM) to maintain the active state in the RPs.
Anycast allows two or more RPs to participate simultaneously within the multicast PIM domain.
Based on one of the methods described in these RFCs, the state of the tree is maintained between two
or more RPs. Using the protocols specified, the RPs also monitor and share active sources so that the
state information is always current. Thus, the administrative domain can have more than one active
RP.
What is very different about Anycast RP from other active/active network mechanisms is that
Anycast requires both RPs to use the same IP address. This is the mechanism that allows receiver and
source routers to register groups with the RP, regardless of the location, or which physical router is
used. The registration messages are simply sent to the physical RP with the closest unicast routing
metric. The IP address used for the RP for Anycast RP must be the same on each router.
Multicast Source Discovery Protocol
Multicast forwarding domains are designed to be secure and separate, just like their unicast
counterparts. However, even private unicast routing domains can be, and most often are designed to
connect to external domains or the Internet. What about multicast domains? Multicast domains are
more fluid by definition and many domains may exist in a single IGP autonomous system. It stands to
reason that some multicast applications will need external reach and therefore a way to bridge
multicast domains and autonomous systems must also exist.
The way routers and networks build a multicast tree can make cross-domain forwarding a
conundrum. In a sparse-mode network we must have both an active source and an active receiver to
build the shared and source trees required to forward traffic. Routers and RPs use the unicast routing
table to perform loop avoiding RPF checks against the sources in the network. If the source is outside
the unicast domain, how do we learn about it? How can we trust that the source is legitimate when it
is outside our control? How do we limit the sources to only those needed without flooding the entire
network like the Internet with every known source?
 There must be a protocol that can track and share active sources between domains. That protocol is
Multicast Source Discovery Protocol (MSDP). MSDP tracks active sources in a network and shares
those sources only with configured neighbors. It allows routers to extend multicast forwarding beyond
internal boundaries, yet maintain a secure multicast posture.
Like BGP, MSDP uses a preconfigured peering relationship to exchange information. MSDP also
uses TCP to securely establish the peering sessions, using port 639 for transport. Each MSDP peer
must be explicitly configured to reach any other peer for which session establishment is required.
Let’s examine how this relationship is formed and what it does.
Referring to Figure 4-17 , R1 is a receiver for multicast group S1. RP1 and RP2 have the same IP
address; however, the Anycast PIM relationship needs to be built via a unique IP address that is
assigned to the local RP device. The following provides a step-by-step flow using Anycast, as
illustrated in Figure 4-17 :

Figure 4-17 MSDP Overview

1. S1 sends a multicast packet to the first hop-designated router. The designated router sends a PIM
register message to RP1.
2. RP1 and RP2 have an established MSDP relationship. RP1 sends a source active (SA) message
to RP2. The SA message is sent via MSDP between RP1 and RP2. The SA message contains the
following fields:
The source address of the data source.
The group address the data source is sending to.
The IP address of the RP.
3. RP2 has the state information (*,G) for receiver R1. After RP2 receives the SA message, the
shortest path tree is built for the S, G flow.
Anycast with MSDP is supported on all Cisco Layer 3 platforms: NX-OS, IOS-XR, and IOS.
PIM Anycast RP
PIM Anycast RP is a variant of Anycast deployments that use PIM to build the active/active
multicast state distribution between the RPs. This process is illustrated in Figure 4-18 .
 Figure 4-18 PIM Anycast RP Overview
R1 is a receiver for multicast group S1. RP1 and RP2 have the same IP address; however, the
Anycast PIM relationship needs to be built via a unique IP address that is assigned to the local RP
device. The following provides a step-by-step flow using Anycast as illustrated in the Figure 4-18 .
1. S1 sends a multicast packet to the first-hop designated router. The designated router sends a PIM
register message to RP1.
2. RP1 and RP2 are configured with the same IP address. Because the register message did not
come from one of the RPs in the Anycast RP set, RP1 then sends a copy of the register message to
RP2. In this case, this register message will use RP1s own IP address as the source address for the
PIM Register message. RP2 receives the register message from RP1 and checks the state table. R1 is
in RP2’s multicast state table, RP2 decapsulates the register packet from RP1 and sends the flow
down the shared-tree to receiver R1. It should be noted if RP2 does not have a receiver in its
multicast state table the register stop is sent in similar manner as the PIM register process.
RP2 sends a register stop back to RP1. This is the state maintenance mechanism between the RPs.
3. RP1 joins the multicast PIM state for S1 by triggering a (S1,G) join message toward S1 and
(S1,G) state is created. After this, RP2 also joins to the source tree by creating a (S1,G) join towards
S1.
Anycast with PIM using IPv4 is only supported with NX-OS. Anycast deployment in IPv6
environment supports PIM Anycast feature in all IOS, IOS-XE and Nexus platforms. The Nexus
platform supports both Anycast PIM and MSDP modes.
Sample Configuration: Anycast RP with MSDP on IOS
The following configurations provide examples for configuring Anycast with IOS (with MSDP),
IOS-XR (with MSDP), and NX-OS (Anycast PIM 4610). In this example, R1 and R2 are the
candidate RPs using loopback 1 as the Anycast RP address. The loopback 0 interfaces of R1 and R2
are used to establish the MSDP relationship and also for PIM. The downstream routers are statically
configured using the RP address of 10.100.1.1. The unicast routing protocol controls the receivers
and/or sources joining one of the active/active RP. Figure 4-19 shows us this example network
diagram.
Note
The recovery from a failure in an Anycast environment when compared to Auto-RP or BSR is
significantly faster. This is because as soon as unicast routing protocol converges, the multicast
control plan RP reachability will take place simultaneously.

Figure 4-19 PIM Anycast RP Configuration

Example 4-13 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-13 Configuring PIM Anycast RP for R1 and R2 in IOS
 Loopback 1 is the Anycast RP address, which is the same on both the RPs.
Note
Make sure you have the router-id configured for unique local node. The same loopback 1 is used in
all the anycast examples.
Example 4-14 shows the downstream router configuration.
Example 4-14 Configuring the Downstream Router in IOS
Click here to view code image
R4 : Downstream router
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim rp-address 10.100.1.1 GROUPS
!
ip access-list standard GROUPS
permit 239.0.0.0 0.255.255.255
 Sample Configuration: Anycast with MSDP on IOS-XR
If we change the RP routers in our network diagram to IOS-XR routers, in this case ASR 9Ks, we
need to adjust our configurations accordingly. The diagram in Figure 4-20 depicts this change to the
network. Example configurations for XR follow the diagram.

Figure 4-20 PIM Anycast RP Configuration

Example 4-15 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-15 Configuring PIM Anycast RP for R1 and R2 in IOS-XR
 Example 4-16 shows the downstream router configuration.
Example 4-16 Configuring the Downstream Router in IOS
Click here to view code image
R4 : Downstream router
hostname R4
!
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip pim rp-address 10.100.1.1 1
!
!
access-list 1 permit 239.0.0.0 0.255.255.255
Sample Configuration: Anycast on NX-OS
Let’s take one more look at the same network, but here we replace the RP routers with Cisco Nexus
switches using NX-OS. Figure 4-21 reflects the changed topology for the accompanying configuration
examples.

Figure 4-21 PIM Anycast RP Configuration

Example 4-17 shows the PIM Anycast RP configuration for Router R1 and R2.
Example 4-17 Configuring PIM Anycast RP for R1 and R2 in NX-OS
 Example 4-18 shows the downstream router configuration.
Example 4-18 Configuring the Downstream Router in IOS
Click here to view code image
R4 : Downstream router
hostname R4
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.4 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.34.4 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
ip pim rp-address 10.100.1.1 1
!
!
access-list 1 permit 239.0.0.0 0.255.255.255
Note
Use caution when configuring Anycast RP. The configuration is quite simple, but the selection of
the RP address on the Anycast loopback can create problems if not designed properly. Although not a
multicast-specific issue, remember that many protocols use loopback addresses as a router
identification, including BGP, MPLS, OSPF, and IS-IS. In each of these protocols, if the router-ID is
not explicitly configured, the highest IP address on a loopback interface will be used. If the Anycast
loopback IP address happens to be the highest, you could end up with multiple routers having the
same router-id! This causes peers and neighbors to crash and routing anomalies to occur. It is always
best practice to explicitly configure router-IDs in all protocols that use them. It is also best practice to
never use the Anycast loopback for any other purpose other than as an RP, such as, for example, a
configured tunnel destination/source or any other non-Anycast mechanism.
Phantom RP
 The concept of a phantom RP is used with BiDir PIM designs. BiDir PIM designs work with
regular RP distribution methods that we described in the earlier sections. Unlike PIM ASM, with
BiDir the RP does not handle any control plane load and RP information. A good BiDir RP design
does not need to provide a physical RP, but rather use a phantom RP. As the name states, the phantom
RP uses a virtual IP address as an RP that is advertised as the RP address but is not locally present on
any router.
Figure 4-22 illustrates a BiDir domain.

Figure 4-22 PIM BiDir Domain

Sample Configuration—Phantom RP on IOS
The following configuration provides a configuration example of a phantom RP using IOS. R1 and
R2 are two routers that have RP information in the PIM BiDir domain.
Example 4-19 shows the Phantom RP configuration for Router R1 and R2.
Example 4-19 Configuring Phantom RP for R1 and R2 in IOS
 In this example, the RP (10.100.1.2) does not physically exist on any device. The subnet to which
the RP belongs, exists with a different mask. The different mask creates a virtual identity for
10.100.1.2. The command ip ospf network point-to-point makes the route of 10.100.1.1 appear with
its configured mask, because by default OSPF advertises all loopbacks as /32. The downstream
routers will see the 10.100.1.2 using the show ip route command, as shown in Example 4-20 .
Example 4-20 Route to 10.100.1.2 on R4
Click here to view code image
R4#show ip route
Routing entry for 192.168.3.0/24, 2 known subnets
Variably subnetted with 2 masks
O 10.100.1.0/30 [110/21] via 192.168.34.1, 00:10:03, Ethernet0/0
O 10.100.1.0/29 [110/11] via 192.168.34.1, 00:10:03, Ethernet0/0
The preferred route(s) is the one with the longest prefix.
R4#show ip route 10.100.1.2
Routing entry for 10.100.1.0/30
Known via "ospf 1", distance 110, metric 21, type intra area
Last update from 192.168.0.2 on Ethernet0/0, 00:10:19 ago
Routing Descriptor Blocks:
……
The Phantom RP configuration example uses a static RP assignment. Phantom RP with PIM BiDir is
compatible with dynamic RP propagation using Auto-RP protocol. Phantom RP propagation using
BSR is not a configuration option at this time; because a virtual address is used that can exist on both
R1 and R2, redundancy is built into the RP configuration. Any failure of the R1 router or the /30 route
configured for the R1 loopback interface, would cause the network to reconverge on the larger /29
subnet route configured for the R2 loopback interface. Because the RP address is virtual, the
mappings would use R2 as the next path to reach the RP until such time as the R1 loopback is
reintroduced to the network.
PIM SSM Configuration
As you read earlier in Chapter 3 , SSM is the only configuration that does not require a RP.
Remember that PIM SSM uses IGMPv3 source-specific joins to subscribe to the appropriate channel,
and the network uses only source trees to forward each flow. Consequently, configuring SSM is very
easy in an established IP multicast network using sparse or sparse-dense mode. Enabling PIM SSM
and defining a range is the only required step and is only required on leaf routers. The SSM source
trees within the existing network form a new SSM multicast domain that coexists but does not
interfere with the existing sparse domain(s).
If the network is using only source-specific applications and is not PIM-configured, PIM-SSM is
very simple to enable. Use the following steps and configuration commands to configure an IP
network for PIM-SSM from scratch.
Step 1. Enable PIM-SSM and define a range for SSM forwarding. Remember the default group
block for SSM is 232.0.0.0/8. If you do not configure a range, the default is assumed.
Click here to view code image
 IOS/XE: ip pim ssm[default | range access-list]
IOS-XR: ip pim ssm range {ip-prefix | none | route-map policy-name}
NX-OS: ssm [allow-override | disable | range access-list]
Step 2. Enable Interfaces for PIM sparse-mode/ (There is no “ssm mode” configuration option, and
no dense-mode operations are required for SSM; thus, sparse-mode configuration is sufficient.)
IOS/XE: ip pim sparse-mode
IOS-XR: router pim
NX-OS: ip pim sparse-mode
Note
IOS-XR supports only sparse mode and it is assumed on any interface configured under the router
pim configuration.
Step 3. Gateway router interfaces, host interfaces, and L3 switch interfaces should be configured
with igmp version 3 .
IOS/XE: ip igmp version 3
IOS-XR: router igmp
NX-OS: ip igmp version 3
Note
For IOS-XR, IGMP version 3 is the default. Use the version command under igmp config to change
versions if necessary.
Note
Make sure that all Layer 2 switches at the leaf edges of the network support IGMPv3 snooping.
Refer to Chapter 2 for additional information on IGMP versions and Layer 2 configurations.
Example 4-21 (for IOS) configures PIM SSM as the only PIM mode available for applications
using the default PIM group addressing. Remember that no RP is required for SSM.
Example 4-21 Sample SSM Configuration
Click here to view code image
RouterX
hostname rX
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
!
interface Loopback0
ip address 192.168.0.X 255.255.255.255
ip pim sparse-mode
ip igmp version 3
!
interface Ethernet0/0
 ip address 192.168.X.X 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
interface Ethernet0/1
ip address 192.168.X.X 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip pim ssm default
!
ip igmp version 3
Summary
A rendezvous point (RP) is the service in the network where both multicast senders and receivers
go to “connect” with their associated counterpart in a shared tree environment. The process of
building a shared tree requires that the network components register active sources, as well as
receivers for a given multicast group to the RP.
IP multicast domains are generally a subset of the entire network infrastructure. This offers an
administrator the ability to have better control over multicast messaging. You can consider a group of
PIM routers with the ability to share the same tree as part of a domain or scope. These scope ranges
are aligned with RP and PIM domains. A scope range can superimpose over each other or be a subset
of one another.
The first step in building a PIM domain for sparse-mode or BiDir is to establish a PIM neighbor
adjacency on a given subnet. The second step is to agree on an RP. RPs and group mappings can be
learned statically using manual configuration at each router or dynamically by using either Auto-RP or
BSR.
There are two ways to dynamically propagate RP information to routers within a domain, Auto-RP
and bootstrap router (BSR). Auto-RP is a Cisco proprietary solution. Rendezvous points using Auto-
RP announce their availability to the mapping agents via the 224.0.1.39 multicast group. The RP
mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a
discovery message to 224.0.1.40. BSR is another RP high-availability mechanism that provides
active/standby functionality of the RP and automatic downstream RP information propagation. The
function of the BSR is to broadcast the RP set to all routers in the domain. The RP cache information
is sent to all downstream routers using PIMv2 message group (224.0.0.13) hop-by-hop to all routers
in the PIM domain.
 Maintaining the integrity of the multicast infrastructure can be a concern in high-availability (HA)
environments. Anycast RP uses a load-balancing technique that achieves active/active RP distribution
for a multicast group. There are two variants of Anycast RP, one based on Multicast Source
Discovery Protocol (MSDP) (RFC 3446) and one based on protocol independent multicast (PIM)
(RFC 4610) to maintain the active state in the RPs.
A phantom RP is used with BiDir PIM designs for HA. BiDir PIM designs work with regular RP
distribution methods, but unlike PIM ASM, BiDir does not handle any control plane load and RP
information. The phantom RP uses a virtual IP address that is advertised as an RP address but not
locally present on any router.
Both PIM dense-mode and SSM do not require the use of an RP. Dense mode is not a recommend
solution for most implementations, as some networking operating systems will not support dense
mode operation. SSM uses IGMPv3 source specific joins to subscribe to the appropriate channel and
the network uses only source trees to forward each flow. Consequently, configuring SSM is very easy
in an established IP multicast network using sparse.
Chapter 5. IP Multicast Design Considerations and Implementation
Chapter 5. IP Multicast Design Considerations and Implementation
In this chapter, we build on the material that has been introduced so far. We look at multicast group
scoping and how multicast networks can be bounded to control the flow of information to provide
security. We explain organizational and global group assignments and how to include address
organization and schemas. Group scoping with hybrid designs and RP placement are examined, to
include MSDP mesh groups and scoped multicast domains. We delve into traffic engineering, how the
elements of Layer 3 devices make forwarding decisions, and how to manipulate those elements for
path selection. IP multicast best practices and security are also covered concerning the network as a
whole and the components that make up that network. Finally, we combine the elements we discuss in
the chapter in a practical case study to solidify what you learned.
Multicast Group Scoping
With the depletion of public IPv4 addresses and the inability to obtain additional numbers from the
Internet Assigned Numbers Authority (IANA), public IPv4 addresses are at a premium. Many
technologies exist to make address management easier, including RFC 1918 and RFC 6598 private IP
addresses and network address translation (NAT). These technologies impact the way we manage IP
addresses internally. In addition, many routing protocols simply work better when address spaces can
be summarized at particular boundaries. Thus, many organizations rely on an IP address schema to
manage internal address assignments.
If you have ever administered an IPv4 or IPv6 network, you know that IP schemas are a very
important part of network design and operation. An IP schema is essentially a map of how IP
addresses are assigned and managed within the network. For example, the schema may prescribe very
specific IP subnets for the network infrastructure while also making available other subnets for DHCP
address assignments for end points and hosts. This is especially relevant for enterprises that may have
limited access to public address space.
Many schemas use particular IP address octets to imply a specific meaning within the organization.
For example, a network architect may assign the private network 172.16.0.0/16 to cover all network
infrastructure address assignments. Administrators may break this block down further to provide
additional control and meaning; for example, the routers in a given location may be assigned
addresses from the 172.16.10.0/24 subnet, derived from the 172.16.0.0/16 supernet.
IPv4 multicast addresses are also a limited commodity. Organizations that roll-out multicast
applications should create a detailed address schema. This schema helps control address assignment
and assists in network operations. If the same IPv4 unicast schema principles are applied to the IPv4
multicast address schema, operations and design engineers can quickly identify applications and
application properties derived through the assigned address.
Scoping is not just about which addresses to assign. Just like the underlying unicast network,
multicast networks must be bounded in order to securely control the flow of information. In many
cases, the boundary of the unicast autonomous system (AS) may coincide with the boundary of the
multicast network, but this is not always the case. The scope of any IPv4 multicast domain should, at
minimum, coincide with the scope of the unicast domain on which it is being overlain. Multiple
multicast domains can overlay on a single unicast network, which can mean that multiple multicast
scopes may be employed in the same unicast domain.
 Some multicast boundaries occur naturally as part of the process of configuring the network. One
obvious boundary is the one that exists between ASs. For unicast routing, the AS boundary is between
the interior gateway protocol (IGP) and the exterior gateway protocol (EGP, most likely this will be
BGP). Although route sharing may be configured between them, the external networks do not speak
directly to IGP routers using the IGP protocol interface. For this reason, BGP routing information is
often excluded from the processes of many internal overlay protocols, like Multiprotocol Label
Switching (MPLS).
Multicast domains can use BGP routes for multicast RPF checks if they are using multicast BGP
(MBGP), reviewed in this chapter. It is rare that all the necessary remote domain routes, like those of
an internal multicast rendezvous point, are shared through native unicast BGP. It is assumed that these
networks are internal only to the domain and therefore should be excluded by policy. It is also
possible that the network may use different paths for external multicast and unicast flows. This can
result in an incongruent network that causes RPF failures in the multicast path. Thus, for most
multicast networks, unicast BGP still creates a natural boundary, in particular when it comes to RPF
checking for loop-free paths. Properly scoping the multicast domain makes it significantly easier to
summarize and secure the domain at the domain edge.
Organizational and Global Group Assignment Considerations
The public IPv4 multicast address blocks detailed in Chapter 1 are assigned by IANA and are not
open for use by an organization for internal independent applications. As with publicly assigned
unicast addresses, nothing prevents deployment of any public address internal to a network, but this
could potentially cause serious conflicts with external-facing routers that have Internet routes. The
same logic applies to IP multicast addresses. When an organization uses multicast privately, they
should select addresses from the IPv4 administratively scoped address block.
Both of these blocks provide a tremendous number of possible addresses. For example, the
administratively scoped IPv4 block is a /8, providing the application architect with the ability to
select from 16,777,216 possible host group addresses for a given application. Very few, if any,
networks will ever need this many addresses. Still, the selection of a group should be rigorously
controlled by some entity with in the organization. Otherwise, group assignment conflicts can occur,
and the groups themselves will have little meaning. It is best to create a group address schema to
permanently address this within an organization.
The considerations necessary to create a multicast address schema are similar to those needed for
a unicast schema. For example, summarization is just as important for multicast as it is for unicast.
Even though each group address is routed as a single address (a /32, or having a mask of
255.255.255.255), it is best to further subdivide the administrative blocks by orderable bit
boundaries that can take advantage of masking. Each contiguous sub-block of addresses can then
represent a particular type of application, giving the address both meaning and additional scope. This
makes security, routing, and other policies easier to implement.
There are several methods of determining the best addressing schema for an organization and
several questions the architect must answer. These questions include:
What is the structure of the organization and how will each line of business use multicast
applications?
What is the scale of the multicast deployment, including both planned and unplanned growth?
What organizational security policy exists for multicast deployments?
 What is the geographical layout of the multicast-enabled network and what is the geographical
scope of each application?
Where are the hosts and where are the sources in the geography?
What address ranges may overlap with Layer 2 MAC addresses?
What plans does the organization have for the use of source-specific multicast?
What is the ability of hosts, servers, and applications to support various address types?
What are the resource utilization parameters for multicast applications?
The answers to each of these questions may affect how the architect subdivides the group address
space. For example, a security policy may dictate that some multicast applications only exist in a
local data center, whereas other applications may have an organization-wide boundary. Another
example could include dividing groups by the amount of resource consumption or by the business
criticality of each application. Important or high-bandwidth groups can receive different treatment
than other groups.
If the blocks are properly subdivided, then creating policy boundaries is a cinch. If not, each group
will need individualized policy statements. The important element to remember is that no one schema
is best for all organizations.
IPv4 Considerations
An IPv4 group address is 32 bits in length and, when written in dotted decimal, is split into 4
octets. The first octet of the private Administrative scope range is set at 239.0.0.0/8. Table 5-1 shows
a simple schema created to separate a small service provider network into meaningful groups. The
division begins with geography, followed by application priority, fulfilling some of the design
concepts previously mentioned.

Table 5-1 Group Scoping by Octet

Some organizations may have very large topologies that require additional complexity. One way to
achieve this is to break down the schema further within each octet. Table 5-2 breaks down the
geography octet into eight regions with up to eight Point of Presence (PoP) locations per region, and
the priority octet into eight priorities, with eight resource consumption models (high bandwidth
versus low bandwidth).
 Table 5-2 Group Scoping by Geography and Priority
Using the schema from Table 5-2 , if the provider needed a group assignment for a core application
or protocol that spanned all PoPs and has a priority/consumption of Infrastructure, then 239.17.0.X
would suffice. The provider would also use 239.84.34.X (239.[0101][0100].[0010][0010].X) as an
assignment for a high-bandwidth, high-priority application with a scope of PoP 3 in the South East
region. The advantage of such a schema is that routers and firewalls can employ wildcard masks to
manage policy statements in the network architecture.
Note
Routers use wildcard masks with IP access control lists (ACLs) to specify what should be matched
for further action, depending on how an ACL is applied. Interface subnet masks read from left to right;
for example, IP address 172.18.100.129 with a 255.255.255.224 mask. This provides an IP device
the delimiting bits between subnet and host. Wildcard masks for IP ACLs reverse this structure; for
example, mask 0.0.0.31 is the reverse of 255.255.255.224 (replacing ones with 0s). When the value
of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be
considered in processing the traffic. A 0 in the mask means that the corresponding address bits must
match exactly with the address for comparison. A 1 in the mask means the corresponding address bit
is variable. Thus, an ACL statement with subnet 10.0.0.0 and mask 0.0.0.255 means that any address
that begins with 10.0.0. will match the statement, because the last octet can be variable.
If the provider wanted to place boundaries on all groups within the Central region, a simple ACL
using a network/mask entry of 239.121.0.0 0.15.255.255 could accomplish the task. Similarly, a
network/mask entry of 239.0.4.0 0.255.251.255 matches any application deemed high resource
consumptive. This schema also has the advantage of allowing for growth or additional scope
constraints that may arise in the future.
This schema also has potentially serious drawbacks. Wildcard mask overlap might occur if certain
subblocks of groups are needed to match a single ACL statement. Layer 2 MAC address overlap
could become a serious issue as well. Additionally, the region, PoP, priority, and consumption model
are not readily apparent in the address, and breakdown of the bits might be necessary to identify the
application’s scope. A simpler schema may do more for human interaction but be more difficult to
draw boundaries around. ACL based boundaries are applicable to the multicast data plane. Efficient
control should be considered in the design for multicast control plane isolation. This will be covered
in detail in this chapter.
The point is, any group schema should address the needs of the organization; there is no one-size-
fits-all approach. If the multicast design overlays an existing multicast network, it may not be possible
to change the schema without disruption; however, the value of such a workable schema is
immeasurable in a large multicast deployment. Keep in mind: If only a few multicast applications are
on the network, there is no need to make a large and complex schema like the one shown in Table 5-2
. Instead, create a table and schema that has meaning and value for your specific multicast
implementation.
Another IPv4 subblock consideration arises when using source-specific multicast (SSM).
Remember that SSM can use both the 232/8 block for global and enterprise use as well as the
239.232/16 block private-only use. Administrators should never assign group space from the 232/8
block unless it is for SSM traffic. Many Layer 3 devices are preprogrammed to act on this block as
SSM and will look to build SSM PIM trees accordingly.
It is also prudent when using SSM to subdivide the public and private SSM blocks further to give
them scope and meaning (as with the preceding example schema). Using the 239.232/16 block for
internal-only applications may provide fewer options for additional scope assignment, but it will still
make bounding the groups easier. Table 5-3 shows a possible subdivision of the 239.232/16 private
SSM subblock using the third octet to identify geographic scope.

Table 5-3 Group Scoping by Octet Applied

In addition to creating an addressing schema that makes sense for your organization, all
administrators should follow several basic rules. Some of these rules are certainly flexible, in that
they can easily and thoughtlessly be broken. Care should be taken to design a schema that meets these
rules. Doing so streamlines configurations, makes troubleshooting easier, and ensures that specific
router features do not interfere with proper multicast operations:
Follow IANA’s addressing guidelines, especially using 239/8 addresses for internal
applications. RFC 2365 describes the use of administratively scoped IP multicast addresses. This
address range should be used for all internal applications. Again, this block is similar in concept to
the use of RFC 1918 addresses for unicast.
Avoid using any group address with the x.0.0.x or x.128.0.x prefixes.
This rule should be somewhat obvious because the 224.0.0.X range encompasses link-local
applications. Using an address in this range could interfere with critical network control traffic that
uses multicast, such as, for example, EIGRP or OSPF. Let these addresses remain reserved as per the
intention of IANA. Routers and switches, including IGMP snooping functions, will be unable to
distinguish between the addresses. Furthermore, consider the 32:1 overlap of IP multicast addresses
to Ethernet MAC addresses. This means you should avoid any multicast address in the [224-
239].0.0.x and [224-239].128.0.x ranges. As an example, notice that the schema in Table 5-3
eliminates this problem by requiring the first elements to begin with bits 0001 and not 0000.
Always use the 232/8 block for SSM applications, including inter-domain one-to-many
applications. RFC 4608 describes the use of the 232/8 address range for PIM-SSM interdomain
applications.
Petition IANA for a publically recognized address from the 224 address range for any public-
facing applications, but only if the application is truly public. Content providers that need to ensure
against an address collision with any other provider or customer on a global scale should consider
this block.
Using Group Scoping for Hybrid Designs and RP Placement
We reviewed the different RP design modes in Chapter 4 . The key considerations for RP
redundancy for any source multicast design are as follows:
1. High-Availability mode : Active/Active or Active/Standby options:
We are aware that Anycast fits the bill for Active/Active mode.
Active/Standby mode is supported by Auto-RP and BSR.
2. Scoping requirement : RP domains and multicast address scheme to scope regions for
multicast:
Scoping requirements need to be reviewed with applications aligned to the scope region. A local
scope will require the source locally assigned to the region and appropriate control methods need to
be determined for the local application not being transported across WAN infrastructure. Application
containment within a scope can be used to limit bandwidth or local application dependency. Adding
multiple local scopes may also increase the administrative overhead; the choice of local scope should
be aligned to the outcome and to the benefits to the network infrastructure.
Care should be taken to maintain the scopes to manageable limits permitted by the application.
Multicast address group selection with an RP for each local scope should be considered.
3. Downstream propagation : Dynamic or static propagation:
The propagation method for an RP should be aligned to the multicast scope addresses. The static
propagation method is to add a static RP address with an associated scope at every downstream
router. This is a painstaking administrative task. Using a dynamic propagation method is preferred
because the configuration for RP and ACL can be done only at the RP responsible for the scope.
Table 5-4 explains the mapping of design features to the RP propagation scheme covered in
Chapter 4 :
 Table 5-4 Comparison of RP Distribution Methods
As shown in Table 5-4 , the actual choice for an enterprise RP design for ASM is not available by
any of the known methods today. The best choice for an Architect would be to have an active/active
implementation, which takes care of scoping and dynamic failover. (A score of 3/3 meets all the three
requirements—Active/Active for high availability, supports scoping, and supports dynamic
propagation.). This is possible by using the hybrid design. Yes, there is a hybrid design for an RP that
leverages multiple protocols to achieve a desired effect for enterprise-scoped multicast design. Table
5-5 outlines the mix of protocols to achieve this design state.

Table 5-5 Hybrid Design Comparison

This hybrid RP design is achieved by using Anycast to establish RP state information and Auto-RP
for propagation of the RP information aligned to scope ranges to downstream routers. Please see
Figure 5-1 to understand the function of the hybrid design.
 Figure 5-1 Hybrid RP Design
In the diagram, RP1 and RP2 act as the RP for the entire enterprise domain. The RP information is
maintained by an Anycast MSDP relationship built between RP1 (10.2.1.1) and RP2 (10.2.1.2). The
candidate RP (10.1.1.1) is used as the Auto-RP candidate. Auto-RP uses 10.1.1.1 as the elected
candidate RP address, because RP1 and RP2 both advertise the same candidate RP address. Auto-RP
ties the multicast scoping access-list at the RP; this ensures the downstream router receives the RP
information with the ACL list attached to the RP scope range dynamically. Example 5-1 provides a
sample configuration.
Example 5-1 Hybrid Design Configuration: Anycast RP with Auto-RP
Click here to view code image
RP1
ip multicast-routing
ip cef
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.1 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 192.168.2.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.1
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.2 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.2
!
access-list 1 permit 239.1.0.0 0.0.255.255
RP2
ip multicast-routing
ip cef
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.2 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.1.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 192.168.3.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.2
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.1 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.1
!
access-list 1 permit 239.1.0.0 0.0.255.255
Example 5-2 shows the configuration for the downstream router.
Example 5-2 Hybrid Design: Downstream Router Configuration
Click here to view code image
ip multicast-routing
ip cef
!
!
interface Loopback0
ip address 10.2.1.3 255.255.255.255
!
interface Ethernet1/0
ip address 192.168.2.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet2/0
ip address 192.168.3.2 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
!
ip pim autorp listener
Example 5-3 shows the RP mapping command output at the downstream router.
Example 5-3 Hybrid Design: Downstream RP Mapping
Click here to view code image
R3# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16 ← Scoped masked range configured using ACL 1 applied to
the candidate RP configuration
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP <- Anycast RP 10.1.1.1 is
propagated via Autp-RP
Uptime: 03:21:32, expires: 00:00:24
R3#
Anycast MSDP relationship at the RP
R2# show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
*10.2.1.1 ? Connect 00:13:45 0 0 ?
R2#
Multicast RP Design with MSDP Mesh Group
We previously discussed the concept of Anycast MSDP based on RFC 3618. The implementation
included a default MSDP peer to create an MSDP Anycast relationship between two RPs to create an
active/active solution. When you are faced with three regions and have to create an enterprise wide
scope between them, using a default peer will not scale because you will only have two RPs in an
active/active mode. For larger scale implementations, Anycast MSDP mesh groups are used.
Anycast MSDP mesh groups operate in the following way: When the RP for a domain receives an
SA message from an MSDP peer, the RP verifies the receiver join requests for the group the SA
message describes. If the (*,G) entry exists, the RP triggers an (S,G) join toward the source. After the
(S,G) join reaches the source DR, a branch of the source tree is built from the source to the RP in the
remote domain. If an MSDP peer receives the same SA message from a non-RPF peer toward the
originating RP, it drops the message.
Figure 5-2 explains the functionality for Anycast mesh groups.

Figure 5-2 Anycast Mesh Group

Three regions are represented in Figure 5-2 . Each region has local sources that have global
receivers and also receivers who participate in enterprise wide multicast streams. To create an
active/active RP model localized to each region participating in the enterprise multicast domain, we
leverage the same hybrid design concept, but with mesh groups. This provides active/active RP
distribution for each region. The design allows localization of local multicast sources and receivers
from state maintenance across the WAN. Example 5-4 demonstrates the configuration.
Example 5-4 Anycast Mesh Group Configuration
Click here to view code image
RP1
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.1 255.255.255.255
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 192.168.2.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.1
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.2 connect-source Loopback1
ip msdp peer 10.2.1.3 connect-source Loopback1
ip msdp cache-sa-state
ip msdp originator-id Loopback1
ip msdp mesh-group ENT 10.2.1.2
ip msdp mesh-group ENT 10.2.1.3
!
access-list 1 permit 239.1.0.0 0.0.255.255
RP2
ip multicast-routing
ip cef
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.2 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 192.168.1.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 192.168.3.1 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.2
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.1 connect-source Loopback1
ip msdp peer 10.2.1.3 connect-source Loopback1
ip msdp cache-sa-state
ip msdp originator-id Loopback1
ip msdp mesh-group ENT 10.2.1.1
ip msdp mesh-group ENT 10.2.1.3
!
access-list 1 permit 239.1.0.0 0.0.255.255
RP3
ip multicast-routing
ip cef
!
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.3 255.255.255.255
ip pim sparse-mode
!
interface Ethernet1/0
ip address 192.168.2.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet2/0
ip address 192.168.3.2 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
!
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.1 connect-source Loopback1
ip msdp peer 10.2.1.2 connect-source Loopback1
ip msdp cache-sa-state
ip msdp originator-id Loopback1
ip msdp mesh-group ENT 10.2.1.1
ip msdp mesh-group ENT 10.2.1.2
!
access-list 1 permit 239.1.0.0 0.0.255.255
Example 5-5 demonstrates a functioning solution.
Example 5-5 Anycast Mesh Group: RP Mapping and MSDP Summary
Click here to view code image
r3#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)
Group(s) 239.1.0.0/16
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:17:44, expires: 00:00:25
r3#show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
10.2.1.1 ? Up 00:27:17 0 0 ?
10.2.1.2 ? Up 00:27:26 0 0 ?
Multicast RP Hybrid Design with Scoped Multicast Domains
You learned about the importance of multicast scoping in Chapter 3 and earlier in this chapter. It is
very simple to overlay the hybrid RP design on the top of the multicast scoped design. Initially, you
must review the local multicast groups that need to participate in the campus or branch domain. Then
consider the requirements for enterprise-wide applications. Now, align these applications with the
multicast IPv4 addressing scheme. When this is complete, use the hybrid RP design to address the
active/active control plane. In Figure 5-3 , we review the enterprise-wide design and overlay the RP
control-plane design.
 Figure 5-3 Enterprise Multicast Scoped Domains
In this example, the multicast application requirement is for enterprise-wide webcasting, local
desktop imaging, and campus security camera multicast video. It is simple to categorize the multicast
into two groups, enterprise-wide and campus. To optimize data transport and control plane for
multicast, the campus source is scoped as a separate multicast domain. The multicast addressing
scheme for the campus is planned accordingly. The RP selection has to be aligned to the multicast
domain, as shown in Figure 5-3 . A global RP is selected with an enterprise-wide scope, and a local
RP is selected with a scope for the local campus. In addition, the enterprise wide RP scope will
cover the campus. The downstream routers at the campus location will learn about the two RPs, one
for the enterprise-wide scope with the multicast address range of 239.1.0.0/16 and one for the local
campus scope with the address of 239.192.0.0/16. Multicast best practices are covered in later
sections of this chapter.
Using the same hybrid design methodology for the RP, Example 5-6 shows the configuration for the
global RP.
Example 5-6 Enterprise Scoped Domain: Global RP Configuration
 Click here to view code image
G_RP1
ip multicast-routing
ip cef
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.1 255.255.255.255
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.1
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.2 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.2
!
access-list 1 permit 239.1.0.0 0.0.255.255
G_RP2
ip multicast-routing
ip cef
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.2 255.255.255.255
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.2
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.1 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.1
!
access-list 1 permit 239.1.0.0 0.0.255.255
Example 5-7 shows the configuration for the local RP.
Example 5-7 Enterprise Scoped Domain: Local RP Configuration
Click here to view code image
L_RP1
ip multicast-routing
ip cef
!
interface Loopback0
! description- this loopback should be !unique to each campus !for multicast local !domain
ip address 10.1.1.10 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.10 255.255.255.255
ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.10
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.20 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.20
!
access-list 1 permit 239.192.0.0 0.0.255.255
L_RP2
ip multicast-routing
ip cef
!
interface Loopback0
! description- this loopback should be !unique to each campus !for multicast local !domain
ip address 10.1.1.10 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 10.2.1.20 255.255.255.255
 ip pim sparse-mode
!
router eigrp 1
network 0.0.0.0
eigrp router-id 10.2.1.20
!
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback0 scope 20 interval 10
ip msdp peer 10.2.1.10 connect-source Loopback1
ip msdp cache-sa-state
ip msdp default-peer 10.2.1.10
!
access-list 1 permit 239.192.0.0 0.0.255.255
Using this configuration, we have achieved an active/active RP implementation in a scoped
multicast environment that addresses the global and local scopes.
The downstream router in the campus will be part of two multicast RP domains, and the RP cache
will appear as shown in Example 5-8 .
Example 5-8 Enterprise Scoped Domain: Campus RP Mapping
Click here to view code image
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:07:43, expires: 00:00:07
Group(s) 239.192.0.0/16
RP 10.1.1.10 (?), v2v1
Info source: 10.1.1.10 (?), elected via Auto-RP
Uptime: 00:07:43, expires: 00:00:07
The branch in this example only participates in the enterprise scope, as shown in Example 5-9 .
Example 5-9 Enterprise Scope Domain: Branch RP Mapping
Click here to view code image
R3#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:07:43, expires: 00:00:07
RP Placement
RP placement is another key aspect in the multicast design. The details that need to be considered
are as follows:
 The RP should be aligned to the multicast scope.
Prefer placing the RP close to the source if possible. This is only applicable to a few sources that
are of key importance to the business. Enterprise-wide deployments for multicast normally use RPs in
the data center for the enterprise scope.
Localization of the RP for local domains reduces the control plane state across the WAN. This is
applicable when we have a MPLS-based service provider circuit in which the number of multicast
states in the WAN is governed by a contractual agreement.
If the number of states in the control plane is between 20 and 50, then another functional device
such as a core switch or a WAN router can be used. Normally, it is not a mandate to have a separate
RP; however, if the number of states is more than 100, a separate RP should be considered at least for
the enterprise global scope.
Multicast Traffic Engineering and Forwarding
An ideal IP multicast network overlay matches the IP unicast underlay in a complimentary way.
Where PIM is concerned, it is simply easier to make forwarding decisions if the underlying unicast
forwarding paths are congruent and ultimately match the unicast forwarding paths. This type of
implementation offers the benefits of low management and operational overhead. Consider Figure 5-4
.
 Figure 5-4 Simple PIM Domain
Figure 5-4 shows a multicast domain in which the underlying IP paths are all unique and simple. If
PIM is enabled on all links, as shown, multicast traffic can simply follow the network paths between
source and receivers as dictated by the unicast routing table. It is clean and simple, and it is definitely
a desirable design goal.
 However, anyone who understands networking knows that this type of uniformity or simplicity is
not always reality. Sometimes we have to make very specific changes to the multicast overlay to
achieve certain desirable forwarding results. Typically, when we want IP traffic forwarding to
conform to a method designed to improve some specific operational aspect of the network, we call
this traffic engineering . Examples of traffic engineering include sending traffic over multiple load-
balancing paths or specific paths with specific characteristics. Let’s explore multicast traffic
engineering a little further by first looking closer at the multicast state maintenance and forwarding
mechanics.
More on mRIB, mFIB, and RPF Checks
A router (L3 device) interface is assigned an IP address from a subnet; this represents the final
physical location of all hosts on a given segment. Reaching a host on a physical segment requires
forwarding packets toward the destination router. IP routing protocols (such as static routing, OSPF,
EIGRP, RIP, or BGP) either manually or dynamically learn the physical paths toward all networks.
The L3 device uses the learned combined address and path information to create a forwarding table
and decision tree. There is a table of all learned network addresses and associated physical paths
with route ranking information, and a subsequent table that indicates which L3 interfaces the router
has chosen to forward toward the destination.
Hierarchically speaking, we refer to these two separate tables as the router information base
(RIB) and the forwarding information base (FIB) . The router populates the RIB by pulling routing
information from tables built by the routing protocols. The IP routing table would be the
RIP/ISIS/OSPF databases, the EIGRP topology table, or the BGP table. The router then derives the
forwarding tree or FIB for each packet from the RIB.
There is a common-sense reason for the separation of these two table types. A router may run many
protocols, and each protocol may record several paths toward an IP destination. The router first
selects the best path(s) from the protocol tables and then ranks each protocol. The RIB consists of
only the best route(s) from the most trusted protocol. This happens at the control-plane layer of the
router. To forward packets, the router must make another recursive decision. The router must relate
the appropriate interface(s) to the route. This is where the FIB comes into play. The FIB is used to
make forwarding decisions or packet manipulation decisions. The use of application-specific
integrated circuits (ASIC) may allow this function to be conducted in hardware, which will improve
the throughput of the device. The FIB is a function of the forwarding or data plane of the router.
Figure 5-5 illustrates the process of building forwarding decision tables. Separating the control plane
from the data plane makes the topology more robust and resilient, allowing the control plane to make
on-the-fly changes or corrections without affecting packet-forwarding until changes are confirmed.
 Figure 5-5 RIB and FIB Population
In the traditional Cisco routing environment, the show ip route command reveals the RIB. The
output in Example 5-10 shows the RIB for a small three-router network. You can see there are routes
learned from OSPF, RIP, static, and from connected networks.
Example 5-10 Basic IOS Unicast RIB: show ip route
Click here to view code image
ASR1K-2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
R 10.0.0.0/8 [120/2] via 192.168.2.1, 00:00:15, GigabitEthernet0/0/0
172.16.0.0/24 is subnetted, 1 subnets
S 172.16.1.0 is directly connected, GigabitEthernet0/0/0
192.168.0.0/24 is variably subnetted, 3 subnets, 2 masks
R 192.168.0.0/24
[120/2] via 192.168.2.1, 00:00:15, GigabitEthernet0/0/0
O 192.168.0.2/32
[110/3] via 192.168.2.1, 00:15:51, GigabitEthernet0/0/0
C 192.168.0.3/32 is directly connected, Loopback0
O 192.168.1.0/24 [110/2] via 192.168.2.1, 00:16:01, GigabitEthernet0/0/0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, GigabitEthernet0/0/0
L 192.168.2.2/32 is directly connected, GigabitEthernet0/0/0
O 192.168.3.0/24 [110/3] via 192.168.2.1, 00:15:51, GigabitEthernet0/0/0
192.168.4.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.4.0/24 is directly connected, GigabitEthernet0/0/3
L 192.168.4.1/32 is directly connected, GigabitEthernet0/0/3
Notice that the RIB table contains information from multiple protocols (RIP, static, and OSPF). The
data plane does not need to know or understand the source of the routing information. It only needs to
derive the best forwarding path for each known IP destination network or subnet. For those familiar
with Cisco Express Forwarding (CEF), the show ip cef command displays the FIB at the data plane
of most IOS routers as demonstrated in Example 5-11 . This CEF table was derived from the above
RIB.
Example 5-11 Basic IOS Unicast FIB: show ip cef
Click here to view code image
ASR1K-2#show ip cef
Prefix Next Hop Interface
10.0.0.0/8 192.168.2.1 GigabitEthernet0/0/0
127.0.0.0/8 drop
172.16.1.0/24 attached GigabitEthernet0/0/0
192.168.0.0/24 192.168.2.1 GigabitEthernet0/0/0
192.168.0.2/32 192.168.2.1 GigabitEthernet0/0/0
192.168.0.3/32 receive Loopback0
192.168.1.0/24 192.168.2.1 GigabitEthernet0/0/0
192.168.2.0/24 attached GigabitEthernet0/0/0
192.168.2.0/32 receive GigabitEthernet0/0/0
192.168.2.1/32 attached GigabitEthernet0/0/0
192.168.2.2/32 receive GigabitEthernet0/0/0
192.168.2.255/32 receive GigabitEthernet0/0/0
192.168.3.0/24 192.168.2.1 GigabitEthernet0/0/0
192.168.4.0/24 attached GigabitEthernet0/0/3
192.168.4.0/32 receive GigabitEthernet0/0/3
192.168.4.1/32 receive GigabitEthernet0/0/3
IP multicasting does not change basic unicast RIB information in any way. The process of unicast
RIB derivation and population is the same for unicast, broadcast, and multicast routes. Routers also
forward multicast packets from the source toward receivers based on the information learned from
the RIB. An inherent danger exists in multicast-forwarding that does not exist in unicast and broadcast
packet-forwarding.
When a network device receives a unicast or a broadcast packet, only a single copy of that packet
exists because it transits Layer 3 interfaces. Broadcasts may have many intended recipients, but a
Layer 3 interface does not make additional copies to send to host interfaces. That is the job of the
Layer 2 switch. Layer 2 switches copy each broadcast frame and flood the copies out each interface
in the associated Layer 2 domain; this is known as packet replication .
IP multicast packets come from a single source but are forwarded toward many Layer 3
destinations. It is very common to have both physical and logical redundancy in Layer 3 networks.
Routers also do not have any inherent way of telling whether a packet is an original or a copy.
Consequently, a Layer 3 router must make an important decision: It must choose which interfaces must
forward a copy of the packet without creating a forwarding loop. The router must therefore have a
way to determine which network paths multicast sources are sending from, where subscribed
receivers are located, and which interfaces are in the path toward those receivers. This is further
complicated by the fact that multicast receivers subscribe only to specific groups. Routers must also
have a way to learn and share information about the groups that have current subscribers, the specific
subscribers, and the sources generating multicast packets.
PIM is the most widely deployed multicast routing protocol; however, the term multicast routing
protocol confuses many engineers. PIM does not learn and share routing information. PIM does not
change, manipulate, or insert information into the unicast RIB of a router. The primary concern of the
multicast routing protocol is to ensure loop-free forwarding over the existing IP network, acting as a
control-plane overlay. This is why a router must maintain a separate multicast RIB and multicast FIB
(mRIB and mFIB) specific to multicast packets. Routers must also populate multicast RIB and FIB
tables using a combination of information from the unicast RIB and the learned source, group, and
receiver information, using RPF checks to determine loop-free forwarding. Refer to the diagram in
Figure 5-6 for a visual illustration of this process.
 Figure 5-6 mRIB and mFIB Population
The show ip mroute command in Cisco IOS reveals the multicast RIB. The show ip mroute output
in Example 5-12 shows the multicast RIB, the same router whose RIB and FIB were previously
examined.
Example 5-12 Basic IOS MRIB: show ip mroute
Click here to view code image
ASR1K-2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:01:12/stopped, RP 192.168.0.1, flags: SJCL
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.2.1
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:01:12/00:02:12
(192.168.1.2, 239.1.1.1), 00:00:07/00:02:52, flags: LJT
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.2.1
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:00:07/00:02:52
(192.168.0.1, 239.1.1.1), 00:00:19/00:02:40, flags: LJT
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.2.1
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:00:19/00:02:40
(*, 224.0.1.40), 00:01:12/00:02:59, RP 192.168.0.1, flags: SJCL
Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.2.1
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 00:01:12/00:02:10
GigabitEthernet0/0/3, Forward/Sparse-Dense, 00:01:12/00:02:59
If the device is using CEF, the multicast FIB is integrated into the CEF table and appears as
follows:
ASR1K-2#show ip cef 239.1.1.1
224.0.0.0/4
multicast
This particular CEF output may not be very helpful. More advanced and modular operating systems
like Cisco IOS-XR process the multicast RIB and FIB more independently. The output from the
commands show mrib route and show mfib route executed on a router running IOS-XR, as
demonstrated in Example 5-13 , shows the distinction between RIB and FIB more acutely.
Example 5-13 IOS-XR MRIB and MFIB: show mrib/mfib route
Click here to view code image
RP/0/RSP0/CPU0:A9K#show mrib route
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
 MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(*,224.0.0.0/4) RPF nbr: 192.168.0.1 Flags: L C P
Up: 00:06:38
Outgoing Interface List
Decapstunnel0 Flags: NS DI, Up: 00:06:38
(*,239.1.1.1) RPF nbr: 192.168.0.1 Flags: C
Up: 00:03:19
Incoming Interface List
Decapstunnel0 Flags: A, Up: 00:03:19
Outgoing Interface List
GigabitEthernet0/1/0/1 Flags: F NS LI, Up: 00:03:19
(192.168.0.1,239.1.1.1) RPF nbr: 192.168.0.1 Flags: L
Up: 00:01:05
Incoming Interface List
Loopback0 Flags: A, Up: 00:01:05
Outgoing Interface List
GigabitEthernet0/1/0/1 Flags: F NS, Up: 00:01:05
(192.168.1.2,239.1.1.1) RPF nbr: 192.168.1.2 Flags:
Up: 00:00:57
Incoming Interface List
GigabitEthernet0/1/0/0 Flags: A, Up: 00:00:57
Outgoing Interface List
GigabitEthernet0/1/0/1 Flags: F NS, Up: 00:00:57
(192.168.2.2,239.1.1.1) RPF nbr: 192.168.2.2 Flags:
Up: 00:02:29
Incoming Interface List
GigabitEthernet0/1/0/1 Flags: F A, Up: 00:01:58
Outgoing Interface List
GigabitEthernet0/1/0/1 Flags: F A, Up: 00:01:58
RP/0/RSP0/CPU0:A9K#show mfib route
IP Multicast Forwarding Information Base
Entry flags: C - Directly-Connected Check, S - Signal, D - Drop,
IA - Inherit Accept, IF - Inherit From, EID - Encap ID,
 ME - MDT Encap, MD - MDT Decap, MT - MDT Threshold Crossed,
MH - MDT interface handle, CD - Conditional Decap,
DT - MDT Decap True, EX - Extranet, RPFID - RPF ID Set,
MoFE - MoFRR Enabled, MoFS - MoFRR State
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
EG - Egress, EI - Encapsulation Interface, MI - MDT Interface,
EX - Extranet, A2 - Secondary Accept
Forwarding/Replication Counts: Packets in/Packets out/Bytes out
Failure Counts: RPF / TTL / Empty Olist / Encap RL / Other
(*,224.0.0.0/4), Flags: C
Up: 00:07:02
Last Used: never
SW Forwarding Counts: 0/0/0
SW Replication Counts: 0/0/0
SW Failure Counts: 0/0/0/0/0
Decapstunnel0 Flags: NS, Up:00:07:02
(*,239.1.1.1), Flags: C
Up: 00:03:43
Last Used: 00:01:29
SW Forwarding Counts: 1/0/0
SW Replication Counts: 1/0/0
SW Failure Counts: 0/0/0/0/0
Decapstunnel0 Flags: A, Up:00:03:43
GigabitEthernet0/1/0/1 Flags: NS, Up:00:02:23
(192.168.0.1,239.1.1.1), Flags:
Up: 00:01:29
Last Used: 00:01:29
SW Forwarding Counts: 1/1/100
SW Replication Counts: 1/0/0
SW Failure Counts: 0/0/0/0/0
Loopback0 Flags: A, Up:00:01:29
GigabitEthernet0/1/0/1 Flags: NS, Up:00:01:29
(192.168.1.2,239.1.1.1), Flags:
Up: 00:01:21
Last Used: never
SW Forwarding Counts: 0/0/0
SW Replication Counts: 0/0/0
SW Failure Counts: 0/0/0/0/0
GigabitEthernet0/1/0/0 Flags: A, Up:00:01:21
GigabitEthernet0/1/0/1 Flags: NS, Up:00:01:21
(192.168.2.2,239.1.1.1), Flags:
 Up: 00:02:53
Last Used: never
SW Forwarding Counts: 0/0/0
SW Replication Counts: 0/0/0
SW Failure Counts: 0/0/0/0/0
GigabitEthernet0/1/0/1 Flags: A, Up:00:02:23
As you can see from the output, the multicast RIB is a table of the sources and groups the router is
currently receiving updates for, from multicast routing protocols like PIM and the host subscription
protocol Internetwork Group Message Protocol (IGMP). As per the process, the list of sources and
receivers is compared against the unicast routing table, checking for exit interfaces and ensuring loop-
free packet delivery using the unicast reverse path.
Even though IP multicast is inherent in the IP stack, multicast overlays are analogous to any other
overlay network, like MPLS, VPNs, GRE, and so on. Each of these protocols also creates and
maintains additional forwarding information and requires an underlying IP network that is complete
and converged. More specifically, the RIB and FIB of the underlying network are the foundation of
any forwarding decision made by the Layer 3 device.
Finally, as previously mentioned in this and earlier chapters, unicast reverse path forwarding
(RPF) checking is the way routers ensure loop-free multicast forwarding. Let us quickly review the
RPF check process: When a multicast packet is received, the router looks up the unicast route toward
the source in the packet header. If the multicast packet entered into the router through an interface that
is in the preferred destination path (derived from the unicast RIB) for the source, the packet is
deemed trustworthy and the router can add the (S,G) to the MRIB table. This is a reverse check, and
the router records the list of incoming interface(s) of the source packet. That does not mean the router
forwards the multicast packet or adds the entry to the MRIB. Additional information is still required.
In order for the router to add the (S,G) entry to the table, an existing (*,G) entry must be in the MRIB,
applicable to Any Source Multicast (ASM). In other words, a downstream source must have
previously expressed interest in the group; otherwise, the router simply prunes the packets, preventing
the multicast stream from flooding the network unnecessarily.
When a router receives an IGMP subscription packet or multicast route update (PIM Join) for a
(*,G), the same RPF check process is followed. Remember, however, that the (*,G) represents a
shared tree. The source is not included in the update, making the root of the tree the RP specified for
the group in the router group to RP mapping. Thus, in the case of a (*,G) update from either PIM or
IGMP, the router RPF checks the forwarding tree against the unicast path toward the RP.
The router builds a list of interfaces that are downstream from the router with interested hosts, the
outgoing interface list (OIL). The OIL in the (*,G) entry represents all the interfaces to which a
multicast packet for the group specified requires packet replication. Now that the router has both an
(S,G) and a (*,G) entry for a particular group, it is ready to replicate and forward packets from the
sources listed in the incoming list toward the receivers listed in the outgoing interface list. In most
cases, routers forward multicast packets, obeying split-horizon rules. The packet must come from an
incoming interface and will be replicated and forwarded down only those interfaces in the OIL. As
you can see, RPF checking is used to govern entries in both the control plane and the forwarding
plane of every multicast router. If any packet or any updated (S,G) or (*,G) fails the RPF check, the
packet is not forwarded and the entry is removed from the mRIB and mFIB.
 Traffic Engineering Using IP Multipath Feature
We have discussed at length the relationship between the unicast RIB, the mRIB, and RPF checks.
But what happens when the unicast RIB has multiple equal-cost path entries for a source, the RP, or
receivers for a given group? Consider the network in Figure 5-7 .

Figure 5-7 Multiple IP Paths

In this very simple network diagram, four equal-cost EIGRP paths lie between the two multicast
routers. The network is purposefully designed to utilize all four paths to maximize efficiency. With
unicast routing, this is referred to as equal-cost multi-path (ECMP). The default behavior of PIM
states that we can only have one RPF neighbor interface in the multicast state table for (*,G) and
(S,G) entries. By default, PIM uses the following rule to declare which interface is the appropriate
RPF interface:
The RPF interface of a (S,G) entry is the interface with the lowest cost path (administrative
distance, or if from the same protocol, the routing metric) to the IP address of the source. The RPF
interface of a (*,G) entry is the lowest cost path to the IP address of the RP. If multiple paths exist
and have the same cost, the interface with the highest IP address is chosen as the tiebreaker.
It is possible to change this default behavior to allow load-splitting between two or more paths, if
required, and there may be many good reasons to do so. Configuring load-splitting with the ip
multicast multipath command causes the system to load-split multicast traffic across multiple equal-
cost paths based on source address using the S-hash algorithm. This feature load-splits the traffic and
does not load-balance the traffic. Based on the S-hash algorithm, the multicast stream from a source
uses only one path. The PIM joins will be distributed over the different ECMP links based on a hash
of the source address. This enables streams to be divided across different network paths. The S-hash
method can be used to achieve a diverse path for multicast data flow that is split between two
multicast groups to achieve redundancy in transport of the real-time packets. The redundant flow for
the same data stream is achieved using an intelligent application that can encapsulate the same data in
two separate multicast streams. These applications are often seen in financial networks. This feature
is leveraged from the network side to achieve redundancy. By using this feature, the network
availability increases the overall resiliency because now a single failure in the network could
potentially affect only 50% of the traffic streams. Furthermore, if you have an intelligent application
that provides redundancy to the same stream by encapsulating in two multicast addresses, then
delivery of the data across the network is guaranteed based on the IP multicast multipath feature.
Things to consider while using this feature in a design are:
Multicast traffic from different sources are load-split across the different equal-cost paths.
Load-splitting does not occur across equal-cost paths for multicast traffic from the same source
sent to different multicast groups.
Note
The multipath hashing algorithm is similar to other load-splitting algorithms in that it is unlikely
that true 50-50 load-splitting will ever occur. It is possible that two unique flows (source to
receivers) could be hashed to forward down the same link, but a single stream from a single source
will not be hashed over more than one link. Table 5-6 delineates the different hash options.
Table 5-6 provides the basic syntax for enabling the feature in IOS and IOS-XE systems.

Table 5-6 IOS Multipath Command Comparison

The topology reviewed in Figure 5-7 provides a use case for multicast multipath. Consider Figure
5-8 , which adds a multicast PIM domain configuration.

Figure 5-8 Multiple IP Multicast Paths

This configuration is shown in Example 5-14 . R1, R2, R3, and R4 represent a multicast domain
with multiple redundant links. There is a desire to split multicast traffic across the four different links
between R2 and R3 to provide distribution of the multicast traffic. This can be accomplished using
the multicast multipath command on both R2 and R3. The source generates traffic for two multicast
groups, 239.1.1.1 and 239.2.2.2. The multicast domain configuration in this example is a simple PIM
ASM with static RP.
 Example 5-14 IOS Multipath Configuration
Click here to view code image
R3 Configuration
<..>
ip multicast-routing
ip multicast multipath s-g-hash next-hop-based
ip cef
!
!
interface Loopback0
ip address 10.3.3.3 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 10.1.6.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet2/0
ip address 10.1.3.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet3/0
ip address 10.1.4.2 255.255.255.0
ip pim sparse-mode
!
router eigrp 1
network 10.0.0.0
!
ip pim rp-address 10.3.3.3
Examine what happens to the RPF checks in the state entries for our multicast groups. Both the
239.1.1.1 and 239.2.2.2 sources send traffic to the respective receiver in the multicast topology.
Example 5-15 shows the path taken by the two streams at R3.
Example 5-15 IOS Multipath RPF
Click here to view code image
R3#show ip rpf 10.1.50.2 239.1.1.1
RPF information for ? (10.1.50.2)
RPF interface: Ethernet2/0
RPF neighbor: ? (10.1.3.1)
RPF route/mask: 10.1.50.0/24
 RPF type: unicast (eigrp 1)
Doing distance-preferred lookups across tables
Multicast Multipath enabled. algorithm: next-hop-based
Group: 239.1.1.1
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
R3#show ip rpf 10.1.50.2 239.2.2.2
RPF information for ? (10.1.50.2)
RPF interface: Ethernet3/0
RPF neighbor: ? (10.1.4.1)
RPF route/mask: 10.1.50.0/24
RPF type: unicast (eigrp 1)
Doing distance-preferred lookups across tables
Multicast Multipath enabled. algorithm: next-hop-based
Group: 239.2.2.2
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Multicast Traffic Engineering: Deterministic Path Selection
In the previous multipath scenario, the network architects have chosen equal-cost paths for
network-forwarding. This decision was likely made to maximize network-forwarding efficiency. If
multicast application traffic is dense enough to consume significant bandwidth, it seems like a wise
course of action to enable multicast multipath. However, in some networks, like financial networks,
there may arise a need to separate multicast data transmission from unicast transmissions across
WAN links.
This design choice could also achieve better optimization of bandwidth for multicast and unicast
applications. Consider a network that is transporting an IP-TV multicast stream. The stream may be
small enough to need only one pipe but large enough to cause resource constraints on unicast traffic,
thereby justifying its own WAN link.
Figure 5-9 illustrates just such a scenario. The administrators of the network have decided that a
corporate IP-TV application consumes a great deal of bandwidth, consuming enough resources to put
critical unicast traffic (Path 2) at risk. The network architect has asked that a redundant, non-unicast
link (Path 1) be maintained for this purpose.

Figure 5-9 Deterministic Multicast Paths

Remember the rule of one RPF path that we just discussed? By default, in this topology, Path1 and
Path 2 are equal-cost links in the EIGRP topology table for 10.1.50.x and 10.1.51.x subnets (multicast
source and receiver subnets). Based on RPF rules, the highest interface IP address is selected as the
RPF interface for the outgoing interface list (OIL), which in this case is Path 2, as shown in Example
5-16 .
Example 5-16 Unicast RIB with Multiple Paths
Click here to view code image
R3# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
D 10.1.1.0/24 [90/307200] via 10.1.3.1, 00:00:11, Ethernet2/0
[90/307200] via 10.1.2.1, 00:00:11, Ethernet1/0
C 10.1.2.0/24 is directly connected, Ethernet1/0
L 10.1.2.2/32 is directly connected, Ethernet1/0
C 10.1.3.0/24 is directly connected, Ethernet2/0
L 10.1.3.2/32 is directly connected, Ethernet2/0
C 10.1.4.0/24 is directly connected, Ethernet3/0
L 10.1.4.2/32 is directly connected, Ethernet3/0
C 10.1.6.0/24 is directly connected, Ethernet0/0
L 10.1.6.1/32 is directly connected, Ethernet0/0
D 10.1.50.0/24 [90/332800] via 10.1.3.1, 00:00:11, Ethernet2/0
[90/332800] via 10.1.2.1, 00:00:11, Ethernet1/0
D 10.1.51.0/24 [90/307200] via 10.1.6.2, 00:00:11, Ethernet0/0
C 10.3.3.3/32 is directly connected, Loopback0
R3# show ip rpf 10.1.50.2
RPF information for ? (10.1.50.2)
RPF interface: Ethernet2/0
RPF neighbor: ? (10.1.3.1)
RPF route/mask: 10.1.50.0/24
RPF type: unicast (eigrp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
Because of the RPF rules, interface e2/0 will always be selected for the multicast flow. Further
complicating the design, e2/0 might also be taken by unicast traffic, meaning ECMP load-sharing will
occur between both Paths 1 and 2. To prevent critical unicast traffic from taking Path 1 (the multicast-
only path) EIGRP is configured to prefer Path 2 (10.1.2.x link) over Path 1 (10.1.3.x). To prevent
multicast-forwarding over the unicast-only path, PIM is not configured on the Path 2 interfaces. If the
network is configured in this manner, the PIM state for IP-TV application traffic has failed RPF
checks and is incomplete.
How can we resolve this issue? What we need is a way to manually adjust the state table—in this
case, the mroute table—to consider the PIM-enabled interface for Path 1 as a potential RPF interface.
Great news! This is the exact purpose of static table entries (in this case, “mroutes”), and they are
easy to understand and configure! Figure 5-10 illustrates this configuration.

Figure 5-10 Static Multicast State Entries

To add static state entries, use the commands outlined in Table 5-7 .

Table 5-7 Static mroute CLI Commands

Note
Notice the language used in the command syntax for IOS/IOS-XE. Do not let the word mroute
confuse you. Remember, the mroute table is not a table of routes but rather a table of multicast state
entries. Adding a static mroute does not add a static state entry in and of itself. What it does add is a
static RPF “OK” when the PIM process checks RPF during state creation. You cannot add state to a
non-PIM interface or when no source or subscribed receivers are present, where the potential for
forwarding does not exist. Much like a unicast static route entry, the underlying physical and logical
infrastructure must match the configured entry to cause the state to occur within the table. Configuring
a static unicast route where no underlying interface or address exists results in a failed route. The
same is true for multicast state entries.
Example 5-17 shows using a static mroute entry to adjust the behavior of PIM state creation to
include Path 1 in the RPF calculation.
Example 5-17 Static mroute Entry Output and Change in Forwarding Path
Click here to view code image
R3# sh running-config | include ip mroute
ip mroute 10.1.50.0 255.255.255.0 10.1.2.1
r3# sh ip rpf 10.1.50.0
RPF information for ? (10.1.50.0)
RPF interface: Ethernet1/0
RPF neighbor: ? (10.1.2.1)
RPF route/mask: 10.1.50.0/24
RPF type: multicast (static)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base
Static state entries can be a useful way to perform multicast traffic engineering in a given simple
network to separate multicast and unicast flows. This is especially valuable in scenarios like the
above, or when asynchronous routing is desired in the network design.
When deploying multicast, it is wise to consider the underlying IP unicast network. The most
preferred network design for IP multicast networks is one where the multicast and unicast forwarding
paths fully align. It certainly simplifies troubleshooting and network management in a profound way.
Network architects should deviate from this practice only when the requirements provide no
alternatives. Static state entries are of course only one way to control deterministic forwarding in
these scenarios.
In large networks with redundant links, to achieve the separation of the multicast traffic from the
unicast, a dynamic way is more desirable. This is achieved using the BGP multicast address family.
With BGP address families, the multicast network needs to be advertised and the next-hop prefix
needs to be resolved via recursive lookup in the IGP to find the upstream RPF interface. In our
example, the address 10.1.50.x (source) and 10.1.51.x (receiver) is advertised in the multicast BGP
address family. Figure 5-11 depicts using eBGP routing to achieve similar results to using static state
entries for traffic engineering.
 Figure 5-11 Deterministic Multicast Pathing Using eBGP
The network administrator would use the eBGP IOS configurations in Example 5-18 on R2 and R3
to achieve path determinism.
Example 5-18 Deterministic Multicast BGP Configuration
Click here to view code image
R2
router bgp 65002
bgp log-neighbor-changes
neighbor 10.1.2.2 remote-as 65003
!
address-family ipv4
neighbor 10.1.2.2 activate
exit-address-family
!
address-family ipv4 multicast
network 10.1.50.0 mask 255.255.255.0
neighbor 10.1.2.2 activate
exit-address-family
R3
router bgp 65003
bgp log-neighbor-changes
neighbor 10.1.2.1 remote-as 65002
!
address-family ipv4
neighbor 10.1.2.1 activate
exit-address-family
!
address-family ipv4 multicast
 network 10.1.51.0 mask 255.255.255.0
neighbor 10.1.2.1 activate
exit-address-family
Examine the changes in multicast path selection behavior using this configuration. The show ip
route command on the same topology shows the IGP RIB with the respective multicast routes. The
command captured at R3 displays the output in Example 5-19 .
Example 5-19 IGP RIB
Click here to view code image
10.0.0.0/8 is variably subnetted, 12 subnets, 2 masks
D 10.1.1.0/24 [90/307200] via 10.1.3.1, 03:59:35, Ethernet2/0
[90/307200] via 10.1.2.1, 03:59:35, Ethernet1/0
C 10.1.2.0/24 is directly connected, Ethernet1/0
L 10.1.2.2/32 is directly connected, Ethernet1/0
C 10.1.3.0/24 is directly connected, Ethernet2/0
L 10.1.3.2/32 is directly connected, Ethernet2/0
C 10.1.4.0/24 is directly connected, Ethernet3/0
L 10.1.4.2/32 is directly connected, Ethernet3/0
C 10.1.6.0/24 is directly connected, Ethernet0/0
L 10.1.6.1/32 is directly connected, Ethernet0/0
D 10.1.50.0/24 [90/332800] via 10.1.3.1, 03:59:35, Ethernet2/0
[90/332800] via 10.1.2.1, 03:59:35, Ethernet1/0
D 10.1.51.0/24 [90/307200] via 10.1.6.2, 03:59:35, Ethernet0/0
C 10.3.3.3/32 is directly connected, Loopback0
r3#
However, the BGP multicast address family takes precedence on the MRIB selection, as
demonstrated in Example 5-20 .
Example 5-20 BGP RIB
Click here to view code image
R3# show ip bgp ipv4 multicast
BGP table version is 3, local router ID is 10.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i- internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i–- IGP, e–- EGP, ?–- incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.1.50.0/24 10.1.2.1 307200 0 65002 i
*> 10.1.51.0/24 10.1.6.2 307200 32768 i
R3#
The RPF for 10.1.50.1 from R3 shows Path 1 as preferred based on the BGP multicast topology
table, as demonstrated in the output in Example 5-21 .
Example 5-21 Deterministic Multicast BGP RPF Result
 Click here to view code image
R3# show ip rpf 10.1.50.0
RPF information for ? (10.1.50.0)
RPF interface: Ethernet1/0
RPF neighbor: ? (10.1.2.1)
RPF route/mask: 10.1.50.0/24
RPF type: multicast (bgp 65003)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base
This method of creating RPF entries for the multicast state machine is a more dynamic than using
static mroute entries, as shown in the previous examples.
In some enterprise networks, customers must transport multicast across provider or non-enterprise
controlled segments. In order to route multicast across these provider links, the service provider
network needs to support the enterprise implementation of PIM and to become a natural part of the
PIM domain. Some providers may not support direct multicast interaction like this on certain types of
links, such as, for example, MPLS WAN services, or they may not support the type of PIM mode
deployed by the enterprise.
In the next example, we use the same deterministic routing scenario from above, but add a non-
enterprise controlled network segment that does not support multicast. As shown in Figure 5-12 ,
Segment A (encompassing both Path 1 and Path 2) is the non-enterprise controlled segment that needs
multicast support. In this example, the provider does not support multicast transport, leaving Segment
A configured with PIM disabled. This would obviously cause RPF failures, spawning incomplete
state entries in the mroute tables of all routers. Figure 5-12 also shows that an easy solution exists for
this type of problem: the use of a GRE tunnel to forward multicast packets.

Figure 5-12 Tunneling Multicast over PIM Disabled Paths

Under such a scenario, the GRE tunnel must establish full IP connectivity between routers R2 and
R3. The GRE tunnel interfaces should be configured for PIM, and a PIM neighborship should exist
across the tunnel. It would not be prudent to configure unicast routing over the newly formed tunnel,
but the transport of MRIB and multicast RPF check still needs to be moved to the overlay segment.
Without the existence of unicast routing, the tunnel interface will fail RPF checking.
In this situation, you have a choice to use static state entries or dynamic BGP multicast address
families to enable multicast transport across Segment A. The principles of MRIB build-up will be the
same and will follow the same rules. The GRE tunnel interface must become the RPF interface.
IP Multicast Best Practices and Security
Every implementation of multicast is unique, in part because every IP unicast underlay is unique.
Multicast networks are often unique in and of themselves, which may place special constraints on
network design. In spite of this uniqueness, certain elements should exist in every multicast network
design.
Following current best practices for network architectures is paramount. Some of these items
include hierarchical design, redundancy, resiliency, high-availability, limiting Layer 2 scope, security,
and so on. Building a strong foundation from which to add services only enhances your ability to
manage, operate, and troubleshoot your network infrastructure. When adding multicast to the network,
the following sections are elements to strongly consider.
Before Enabling PIM
Many network engineers make the mistake of simply turning on multicast in complex network
topologies with the expectation that it will instantly function in an ideal manner. Remember, if it was
that easy, we would be out of work.
There are several items that must be considered before configuring a network for IP multicast:
CEF/dCEF/MLS CEF considerations for those platforms that require it. Without CEF on these
platforms, multicast packets are process-switched which can overwhelm the central processing unit
(CPU) of the networking device (very bad).
Unicast routing must be enabled and operational on the network. Remember that PIM is an
overlay to a successful L3 unicast design. Carefully consider any redundant paths in the network,
looking for possible asynchronous routing that could cause RPF check failures.
Consider the multicast applications being placed on the network. Network architects should
select the most ideal multicast features and configurations for these applications.
Remember that groups in the 224.0.0.* range are reserved for routing control packets. A proper
schema should be a design requirement. When creating your schema, do not forget to account for (and,
if necessary, eliminate) MAC overlapping group ranges, as described in Chapter 2 !
The administrator should be familiar with IPv4 and IPv6 multicast routing configuration tasks and
concepts.
Administrators should be aware of the various multicast configurations and features for a given
platform. Not all platforms support all features or modes. Make sure you do not select a PIM mode
(such as, for example, dense-mode or PIM-BiDir) if it is not supported universally across the
intended PIM domain. This chapter establishes the following protocol selection guidelines:
Dense-mode is not recommended except in legacy environments where it may already exist. It is
likely that DM is not supported by your current platform.
In general, if the application is one-to-many or many-to-many in nature, then PIM-SM can be used
successfully.
 For optimal one-to-many application performance, SSM is appropriate, but it requires IGMP
version 3 client support.
For optimal many-to-many application performance, bidirectional PIM is appropriate, but
hardware support is limited to certain Cisco devices
Table 5-8 provides an example of multicast applications and the relationships between sources and
receivers.

Table 5-8 Application Examples

You should have a proper PIM design for each desired protocol version, with an understanding
of which protocol you will run and why, before moving to implementation.
In addition, each platform and each operating system has specific tasks and configuration
parameters required to enable IP multicast functionality. For more detailed information, please refer
to the individual configuration guides for each operating system found at Cisco.com . This book uses
examples from the latest versions of each operating system at the time of writing. Remember to
review current configuration guides for changes.
General Best Practices
Multicast can be your best friend or your worst enemy. As the manual for the dangerous equipment
hidden away in your garage suggests, “be sure to read, understand, and follow all the safety
procedures.”
Tuning the Network for Multicast
Most of the control-plane stress in a multicast network will be at the access edge, as well as at any
RP routers. This occurs because receivers and sources are located on the edge of the network. A
routed network may have only a few branches, but the edge devices must efficiently replicate packets
for many potential interfaces, in addition to managing the IGMP subscription process. It is best to
maximize efficiency at the edge for this reason, especially if the expected multicast usage is high with
multiple types of many-to-many or one-to-many applications.
Architects should start by ensuring that the Layer 2 forwarding domain is fast, efficient, and loop-
free. Multicast can substantially increase Layer 2 flooding. Ultimately you should strive for a design
that limits flooding domain size by controlling VLAN sprawl and using Spanning Tree Protocol (STP)
wisely. Limiting VLAN sprawl and excessive use of VLANs on access switches eliminates massive
packet flooding across a number of switches. Unnecessary VLANs should be effectively pruned from
switch trunks. Manual configuration of interfaces and the use of virtual trunking protocol (VTP)
transparent mode should be considered to enforce this policy. In addition, storm control can help
alleviate potential configuration issues with multicast sources, protecting switches from inappropriate
multicast and broadcast flooding.
IGMP snooping is also an excellent way to limit flooding behavior at the Layer 2 edge. Remember,
without IGMP snooping, flooding of multicast packets will occur VLAN- or switch-wide, depending
on configuration. If a VLAN spans many switches, the results of excessive flooding can take a toll on
switch-forwarding resources. Remember that IGMP snooping limits replication and flooding to only
those ports with subscribed hosts.
Note
If you have a network in which multicast is only local to a given Layer 2 domain (there is no
multicast-enabled L3 gateway and no PIM), IGMP snooping is still your friend. However, remember
that IGMP requires that an IGMP querier be elected for each VLAN with IGMP subscriptions. If there
is no Layer 3 device, and no PIM configuration, switches by default assume there is no gateway and
will not elect a querier as part of the natural process. To resolve this issue, a network administrator
should either configure one device in the switch domain with PIM, or manually configure one switch
as the IGMP querier.
Network architects should consider designs that make use of new technologies like the Cisco
Virtual Switching System (VSS) to eliminate STP-blocked ports in the forwarding path. This helps
optimize failure convergence times as well as packet flow through the edge, maximizing available
bandwidth and predictability. If such a design is not possible, STP should be tuned to improve STP
convergence. Rapid STP should be a minimum requirement for the multicast network edge.
Because multicast is an overlay on the unicast topology, multicast traffic will not work if there is
an IP unicast network outage. If multicast communications are mission critical, or at the very least are
important to the business, the same care and effort put into the unicast network design should be put
into the multicast overlay design. It is also wise to tune and adjust the IP unicast network to maximize
IP multicast traffic throughput and to minimize network disruption.
IP unicast interior gateway protocols (IGPs) used for routing (RIP, EIGRP, OSPF, and so on)
should be both secured and optimized in the network. Exterior gateway protocols (BGP) should also
be secured and optimized, especially if they are a part of the multicast domain control plane as
described earlier. When possible, routing protocols should be locked down and adjacencies should
be verified using ACLs and MD5 encryption when possible. This prevents intruders from injecting
attack-based routing information into the network, possibly disrupting the flow of multicast traffic.
Protocol timers should be tuned in favor of fast convergence. For example, EIGRP can use lowered
hello and dead timers to increase failure detection and recovery speeds. OSPF timer adjustments may
also be warranted, including optimizing SPF, hello, dead-interval, and LSA timers. BGP perhaps
allows for the most flexibility for adjusted and optimized timers. Be sure to understand fully the
implications of any protocol tuning before you proceed with configuration, and ensure that any timer
changes are implemented universally. Mismatched timers can cause major protocol adjacency flaps
for some protocols. The bottom line: the faster the unicast network converges on changes and
disruptions, the fewer interruptions there will be to IP multicast traffic.
Remember also, multicast convergence is not aligned to the convergence results you get with
unicast. If you tweak unicast convergence to one second, then multicast convergence will be a factor
of five to six times unicast convergence. Tweaking of the multicast control plane via sub-second PIM
and RPF back-off feature can reduce this gap in convergence between two and three times compared
to the standard. If you choose to make multicast timing adjustments a requirement, then multicast
tweaks should be assessed with the stability of the control plane as the main goal, keeping in mind the
total number of states. When these timers are changed on any router in the network, all PIM routers in
the network should be configured with matching timers.
Finally, network architects should ensure that the IP unicast network is robust, reliable, and simple.
Architects should look for any situations that may affect multicast-forwarding. Look for tunnel
interfaces, or asynchronous routing that may negatively affect RPF checks. Be aware of other network
protocols like MPLS or VPNs (for example, GetVPN or DMVPN). Special considerations may be
required for certain technologies or topologies when it comes to multicast. Always check with the
latest design guide for those technologies implemented on the network.
Manually Selecting Designated Routers
On any segments with multiple PIM speakers, PIM software will select a PIM designated router
(DR). Remember, the role of the DR is to forward multicast data for any groups attached to the
segment. That means that it serves as the segment multicast-forwarder, as well as the control point for
communication with any RPs for each group. The DR is essentially the PIM manager for that segment.
For an ASM network, this means the DR sends PIM join/prune messages to any RPs for any group
subscriptions on the segment. The ASM DR will look up the corresponding RP mapping for each
group and begin the control process. This also includes sending unicast-encapsulated multicast
messages to the RP from any source on the segment, registering the source and completing the shared
tree.
When the DR receives a direct IGMP membership report from a directly connected receiver, it is
easy to make a complete shortest-path tree because the DR is obviously in the forwarding path.
However, there is no rule that the PIM DR must be in the shortest-path tree. Examine the PIM network
in Figure 5-13 .
 Figure 5-13 Out-of-Path Designated Router
In this network, routers R3 and R4 provide redundant paths for the unicast network. The source,
239.10.10.10, however, is reachable only via the primary unicast path running between R4 and R2. If
the PIM process has elected R3 as the designated router for the LAN segment connecting R3 and R4,
the DR for the segment would not be in the forwarding path. Although this design would still work, it
would also be inefficient. Why not make R4, the in-path next-hop router, the PIM-DR? It would
certainly improve efficiency, especially if there are a large number of hosts on the LAN segment and
many groups to manage.
You should also consider the impact of making all redundant paths PIM-enabled in this example
network. Look at the adjustments made to the network in Figure 5-14 . In this case, routers R3 and R4
are now redundant routers using a mechanism like Hot Standby Router Protocol (HSRP) to load-
balance unicast traffic and all upstream paths are PIM-enabled. Like with HSRP, the administrator
would also like to load-balance the PIM management between the two hosts. If there are many
multicast-enabled VLAN segments terminating on these routers, you can achieve similar results by
alternating the DR between R3 and R4 for each VLAN (even and odd), as shown. The router
providing the DR should align with the active HSRP peer for that VLAN. This helps align traffic
between unicast and multicast flows using the same gateway router, while also providing failover for
multicast flows. This is configured using the DR priority interface command option, as explained in
Chapter 3 .

Figure 5-14 Load Balancing with Designated Routers

Note
 In many modern Cisco networks, the concept of discrete paths and gateways is fading in part
because of technologies like Cisco’s Virtual Switching System (VSS) and virtual PortChannel (vPC)
that allow a pair of L2/L3 switches to appear as a single switch and gateway. This eliminates the
need to specify the DR function in designs like the one above. Consider that in a VSS design, for
example, the two switches/routers in Figure 5-14 , R3 and R4, could actually be a single pair of
Layer 3 switches acting as a single gateway. This is the preferred way to design LAN access for
multicast if the technology is available.
For PIM-SSM networks, inefficient DR placement in the path can be more problematic. The SSM-
DR generates (S, G) PIM join messages that propagate through the path back toward the source. The
path from the receiver to the source is determined hop by hop, and the source must be known and
reachable by the receiver or the DR. If the DR is not in the direct path toward either the source or the
receiver, unintended consequences can occur.
In either case, for large networks, manually forcing the outcome of DR elections to optimize
network behavior is sometimes best. This is especially true at the network edge where sources and
receivers are connected. Properly selecting the DR can improve both control plane and data-plane
efficiency.
As discussed previously, PIM routers use information contained in the PIM hello message headers
to determine the DR. Any PIM-speaking router on the segment can become the DR, assuming it meets
the selection criteria. The rules of PIM-DR selection force the router with the highest priority to
become the DR. If the DR priority is the same, the router with the highest IP address in the segment is
elected DR. PIM-DR priority values range from 1 to 4,294,967,295, with the default being 1. If no
priority is selected, the IP address of the PIM router is used, the highest address becoming the DR.
Remember, the PIM address is derived from the interface that sent the hello message.
To change the PIM-DR priority on IOS or NX-OS interfaces, use the ip pim dr-priority <0-
4294967294 > command. The same function in IOS-XR is done under the router pim submode using
the command dr-priority <0-4294967294 >; this can be applied as an interface default or per
interface under the submode.
You can display the configured DR priority and DR-elected router address for each interface by
issuing the command show ip pim interfaces in IOS/XE or show pim interface in IOX-XR. For NX-
OS, use the show ip pim neighbors command instead. The output in Example 5-22 is from an IOS
router, notice the DR Prior field and the DR address field in the output:
Example 5-22 show ip pim interface Command Output
Click here to view code image
CR1#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.63.3 Ethernet0/0 v2/D 1 30 1 192.168.63.6
192.168.43.3 Ethernet0/1 v2/S 1 30 1 192.168.43.4
192.168.31.3 Ethernet0/2 v2/S 1 30 1 192.168.31.3
192.168.8.1 Ethernet0/3 v2/S 0 30 1 192.168.8.1
Basic Multicast Security
Security is an important part of any network or application design. In years past, many engineers
considered security a set of point features that were an afterthought to the design of the network, much
like an overlay. The technology industry in general has learned that this is both an ineffective and
dangerous approach to securing networks and applications. Today’s networks must be designed from
the ground up with intrinsic security as a main essential objective.
Attacks to multicast networks can come in many forms. Because multicast is an overlay to an
existing, functional unicast network, the same attack vectors and weaknesses that affect a unicast
network impact multicast-forwarding. If the unicast network is not secure, the multicast network is
equally vulnerable. In addition, IP multicast inherently increases the surface area of possible attack
vectors.
Abstractly speaking, the key factors to security design are integrity, confidentiality, and availability.
When it comes to IP multicast end points, any security mechanism that enables these factors to protect
unicast applications should also be applied to multicast applications. For example, an enterprise
security policy may require that encryption with authentication be enabled on any mission critical,
secure applications. Because multicast packets are essentially just IP packets, this type of security
policy should be applied equally to multicast applications. Another example is protecting multicast
routers, switches, and other infrastructure from unauthorized access.
Generally, the objective of most network-concentrated security policies is to protect network
availability for applications and users. Attack vectors and weaknesses used to induce availability
security incidents are either focused on network resources (such as, for example, bandwidth or queue
space), or the network devices themselves. Examples of these types of attacks and vulnerabilities
include denial-of-service (DoS) attacks, unauthorized access of network devices, protocol spoofing,
packet interception, and others. This section does not address the myriad ways in which a network or
multicast domain can be compromised, but instead it attempts to deal mainly with protecting the
availability of the multicast network.
Protecting Multicast Control-plane and Data-plane Resources
A network infrastructure or device that is overwhelmed with a specific task will not be able to
adequately address the requests of other processes. As we require the network to perform additional
functionality or run more processes, we begin to spread those resources (CPU, memory, TCAM, and
so on) across multiple functions. Care must be taken to limit how those resources are utilized.
Control-plane policing (CoPP) is beyond the scope of this book; however, it is prudent to understand
how this technology can be utilized to protect network devices and ultimately the integrity of the
entire network infrastructure.
One common way to protect multicast control-plane resources is to limit the number of state entries
that a multicast router allows in the MRIB. This protects the router from misconfigured network
consumption as well as potential denial-of-service attacks. It also protects the underlying IP unicast
network control-plane resources by preventing the CPU and memory from being overwhelmed by
multicast route churn. This is known as a state maximum or a route-limit . See Table 5-9 for
command details.
 Table 5-9 Limiting Multicast State Entries
These commands ultimately limit the total number of (*,G) and (S,G) entries that can be installed in
a router. Valid limits are dependent on platform, but for a typical IOS router they are between 1 and
2,147,483,646. The default value is to allow the maximum. When the router reaches the configured
route limit and a new PIM join is received with a new potential group, the router issues a warning
message and fails to install state for that entry. No existing entries are removed.
You can also apply a similar limit to gateway routers running IGMP by limiting the number of
IGMP-managed group entries in the state table. The ip igmp limit , or maximum groups command
prevents any installation of additional group entries into the IGMP cache after the limit is reached.
This also prevents the router from issuing any PIM messages for any groups exceeding the limit. Table
5-10 shows the command usage.

Table 5-10 Limiting IGMP Subscription Entries

These commands can be applied either globally or at the interface level. IOS XR uses a different
command for each command locality. In addition, the IOS version of this command allows
administrators to create a list of exceptions using an ACL. An explicitly excepted group will not be
limited, regardless of cache size. Nexus platforms can also make exceptions, but they do so by policy
maps as opposed to ACLs.
Another way to allow IGMP to prevent unwanted state creation and PIM messaging is to create an
explicit list of allowed and denied groups. This is a common security requirement in many networks.
Table 5-11 provides the commands necessary to limit group management by ACL.
 Table 5-11 Use ACLs to Permit Multicast Subscriptions
Finally, protecting data-plane resources is also an important part of basic multicast security. One
way this can be achieved is by simply rate-limiting the number of allowed multicast packets on a
given interface. In IOS, this is done using the using the ip multicast rate-limit command, as follows.
Click here to view code image
ip multicast rate-limit {in | out} [video | ​whiteboard] [group-list access-
list] [source-list access-list] kbps
To achieve rate-limiting for multicast in XR and NX-OS, a simple rate-limit can be used under the
normal modular quality-of-service (QoS) configuration CLI. IOS devices can also apply multicast
traffic limits in the same manner. For more information on how to use modular QoS to rate-limit
multicast traffic, see the individual QoS configuration guides for each platform. The multicast-rate-
limit should be taken care by the QoS design and its parameters; it is not a must to have multicast
rate-limiting unless there is a specific requirement for application usage.
Securing Multicast Domains with Boundaries and Borders
Just as with unicast networks, multicast boundaries should exist where the security policy and the
needs of the application dictate. Remember the earlier discussion around scoping. Scoping addresses
and bounding a domain within the construct of the IGP are important for securing the domain. You do
not want your multicast packets leaking outside the logical domain scope. A well-planned addressing
schema, wise RP placement, and a clear understanding of natural network boundaries make scoping a
domain significantly easier.
In many cases, a boundary can occur between two domains overlaid on the same IGP. These would
not necessarily be natural boundaries and should be enforced with policy. In other cases, like in large
network-wide domains, it means that a natural boundary will occur at the IGP edge of the network.
For example, the scope of an internal multicast application that is corporate-wide will end at any
Internet-facing interfaces or at the edge of the autonomous system (AS).
The network administrator can make an AS boundary simply by not configuring PIM on any
external interfaces. If PIM is not required outside the AS, there is no need to have those interfaces
included in the PIM domain. This creates a natural PIM control-plane boundary between the routers
within and without the PIM domain. Figure 5-15 depicts this natural control-plane edge with the
Internet, as well as a configured boundary for the global multicast domain.
 Figure 5-15 Multicast Boundaries
The definition of a domain that we have used thus far is fairly loose and, in the case of Figure 5-15
, follows the natural control-plane edge. Some applications and environments may need a more
restrictive way to define boundaries. In addition, for locally scoped applications, those defined by
administratively scoped group addresses, it may be necessary to create boundaries and scope outside
those services offered by routers. Firewalls and router access lists (ACLs) can (and in most cases
should) use rules to prevent the spread of multicast information beyond a specific boundary. In the
same way, multicast hosts can also be configured for similar security measures if it is warranted.
Application developers can also be part of the bounding process. One way the application can be
bound is by effectively using the time-to-live (TTL) counter in multicast source packets to limit the
scope of transmission. Scope, in a network, is the number of times (usually by a router) a packet can
be forwarded, known as hops. IP multicast packets have IP headers identical to those used in unicast,
and the normal rules of transmission apply. Each router in the path inspects the TTL counter of the
packet. If the router forwards the packet the TTL counter is decremented by one. If the application
sets the multicast IP TTL to 4, then the region is scoped to four hops. This is a good way to ensure that
local data stays local.
Perhaps the best way to segment a domain or region is to configure hard network boundaries. There
are different ways of achieving this. One easy way is to prevent the spread of dynamic multicast
group mappings. All Cisco router operating systems provide a way to limit the scope of both the
Auto-RP and BSR updates. If routers outside the configured scope do not have the RP mappings, they
will not be able to participate in tree-building within that domain. There are two ways to limit the
scope, depending on the protocol announcement method in use.
The first should be fairly obvious, using the scope option in the Auto-RP commands, as shown
here:
Click here to view code image
ip pim send-rp-announce Loopback0 scope 3
ip pim send-rp-discovery Loopback0 scope 3
The scope option sets a TTL in the RP-Candidate and RP-Announce messages. If the domain has
only four routers, then setting a scope to three should be sufficient to prevent the proliferation of the
group mappings for that domain. Using the following IOS/XE commands, for example, accomplishes
this boundary requirement. The ability to control the multicast RP control plane via TTL is one of the
advantages of using Auto-RP in a scoped domain.
There are, of course, more granular methods of controlling Auto-RP announcements as well. But
this method also applies to creating a secure border for any multicast group address or schema. One
easy way to provide a boundary around a domain and Auto-RP announcements is to use the boundary
interface-level configuration command, as shown in Table 5-12 .

Table 5-12 Configuring Multicast Boundaries

To see how this works in practice, review the setup in diagram Figure 5-16 . This simple multicast
implementation uses an Auto-RP configuration and two multicast domains: global scope 239.1.1.0/24
and local scope 239.192.0.0/16. The diagram only shows two RPs each for global and local; the RP
HA portion of the setup is not shown.
 Figure 5-16 Multicast Boundary Example
We can now examine the configuration required for this setup. R4 router is the spoke WAN router;
we will add a multicast boundary configuration on this router. Example 5-23 shows the commands
needed to enable the boundary configuration.
Example 5-23 Configuring a Proper Multicast Boundary List
Click here to view code image
ip access-list standard LSCOPE
deny 224.0.1.39
deny 224.0.1.40
deny 239.192.0.0 0.0.255.255
permit any
The ACL LSCOPE denies Auto-RP advertisement leakage outside the domain (which will end at
interface Etherenet0/0) by denying groups 224.0.1.39 and .40. The data plane for the local groups in
the 239.192.0.0/16 supernet is also contained within the local scope by using a deny statement. All
other groups are allowed in the access-list with the permit any statement at the end.
The next step is to apply the access-list to the boundary interface (Ethernet0/0), using the ip
multicast boundary command with the ACL name, as shown in the output in Example 5-24 .
Example 5-24 Applying a Multicast Boundary List
Click here to view code image
r4-spoke#show running-config interface ethernet 0/0
Building configuration...
Current configuration: 118 bytes
!
interface Ethernet0/0
ip address 10.1.3.2 255.255.255.0
ip pim sparse-mode
ip multicast boundary LSCOPE out
end
Note
Make special note of the out keyword used in Example 5-24 . If the out keyword is not applied, the
router assumes that it is an implicit deny and will not allow important group mappings to occur. In
this example, it would not allow global group mappings to occur in the local scope.
Issuing the show ip pim rp mapping command on R3-WAN shows the global multicast group block
239.1.1.0/24 and global RP mappings, as demonstrated in Example 5-25 .
Example 5-25 Boundary Group Mapping
Click here to view code image
r3-WAN# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.1.0/24
RP 192.168.2.2 (?), v2v1
Info source: 192.168.2.2 (?), elected via Auto-RP
Uptime: 07:39:13, expires: 00:00:21
r3-WAN#
The 'show ip pim rp mapping' at local domain node (R5) is:
r5-LRP# show ip pim rp map
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)
Group(s) 239.1.1.0/24
RP 192.168.2.2 (?), v2v1
Info source: 192.168.2.2 (?), elected via Auto-RP
Uptime: 07:22:34, expires: 00:00:26
Group(s) 239.192.1.0/24
RP 192.168.5.5 (?), v2v1
Info source: 192.168.5.5 (?), elected via Auto-RP
Uptime: 07:22:34, expires: 00:00:25
r5-LRP#
The local RP will have overlapping of two multicast domains and two RPs (global and local RP).
BSR uses a less centralized but more sophisticated method of limiting the scope of BSR
advertisements, as shown in Table 5-13 .

Table 5-13 PIM Border Configuration Commands

The bsr border command is issued globally in NX-OS, on the interface in IOS/XE and under the
router pim interface subcommand mode in IOS-XR. The command creates a BSR border (boundary),
preventing BSR advertisements from being forwarded on any participating interfaces. Consequently,
if the scope of a region is still four routers, each router with an external-facing interface would need
to be configured with this command. Although this requires additional configuration work, the border
becomes more flexible and granular, addressing a major weakness in the Auto-RP scope option. (The
scope should be equal to the network diameter—the number of hops—but the placement of the RP
may not be ideal in relation to the required hop count.)
Note
NX-OS also provides the option of applying the bsr border command globally and then allowing
specific interfaces to forward using the ip pim bsr forward interface configuration command.
The primary intent of this section is to illustrate that multicast domains are a little different and
more fluid by definition than their unicast counterparts. Where and how you divide domains is a
critical design decision that has a myriad of consequences. It affects the scope and topology of an
application, the size of the MRIB and MFIB tables, the security of the applications, the need for
specialized configuration, and the types of devices that will access the application.
There are other ways to control dynamic RP-to-group mapping. The ip pim accept-rp command is
used in conjunction with the RP address as an optional ACL used to limit dynamic RP learning to
specific group addresses. If the RP is also the first hop designated router (DR) for directly connected
sources, PIM register packets will not be filtered using the ip pim accept-register command. Table
5-14 shows the command syntax for the accept-rp configuration option.

Table 5-14 Accept-RP Commands

The configuration in Example 5-26 accepts join or prune messages destined for the RP with an IP
address of 10.3.3.3 destined for the multicast group of 239.1.1.1.
Example 5-26 Accept-RP Configuration Example
Click here to view code image
ip pim accept-rp 10.3.3.3 Group_Address
!
ip access-list standard Group_Address
permit 239.1.1.1
It is important to have a clear delineation between the edge of the multicast network control plane
and other network connections, especially external connections, such as the Internet. The first and
most important step to accomplish this is to disable PIM on any interfaces not in the PIM forwarding
path or any externally facing interfaces. This should prevent a neighbor relationship from forming on
these interfaces. It is common practice to install a protective ACL on external interfaces as well (such
as anti-spoofing or other basic filters). These ACLs should end with a deny ip any any and should
not include a permit for any unwanted multicast traffic.
However, it occurs in some broadcast networks, like Metro-Ethernet, that PIM is needed on a
broadcast media where both internal and external paths may lie. In other cases, PIM neighbor
relationships may be undesirable for certain peers but desirable for others. Either way, a method is
needed to filter out unwanted neighbors, permitting PIM hello messages only from explicit addresses.
The neighbor-filter command, shown in Table 5-15 , can assist with this configuration need.

Table 5-15 Neighbor Filter Commands

Finally, any other measure that a network administrator would use to create a boundary between
networks is appropriate to apply to the multicast edge. Firewalls are an excellent device for edge-
network separation, and many firewalls, including the Cisco ASA firewall appliance, can inspect
multicast packets. A single-context firewall in routed mode will be able to participate in the multicast
control and data plane. For multi-context firewall deployment, it is recommended to deploy firewalls
in transparent mode for multicast support for security and state inspection. Also, network
administrators should ensure that corporate security policies include IP multicast security measures at
any level where it is appropriate in the infrastructure or application architecture.
Protecting Multicast RPs
The key to protecting multicast RPs is to protect the control-plane resources of the RP itself.
Typically, RPs are placed near the heart of the network, away from the network edge. With the
exception of PIM-BiDir, the RP does very little multicast forwarding, unless it is directly in the flow
of traffic. Consequently, protecting the data plane should be relatively easy to do by removing the RP
from the main multicast data path.
If the network is large, or if there are many multicast streams, the RP can be taxed. Remember that
when a new source starts transmitting in a PIM sparse-mode network, the packets will be
encapsulated and sent using unicast messages to the RP. By default, a RP is therefore vulnerable to
accepting registrations from inappropriate DRs for inappropriate groups, as well as to accepting
more registrations than it may be able to handle in memory.
It is a good idea, to lock the RP down so that it accepts registrations only for groups that are part of
an explicit list. Using an ACL, an accept-register list does just that. This security feature allows
control over which sources and groups can register with the RP from the FHR. Table 5-16 lists the
commands needed to lock out unwanted group registrations at the RP.
 Table 5-16 accept-register Commands for RPs
Aside from explicitly limiting the exact entries allowed to create state on the RP, you can also limit
the rate at which state entries can be created. The multicast registration process can be taxing on the
CPU of the designated router (DR) and the RP if the source is running at a high data rate or if there are
many new sources starting at the same time. This scenario can potentially occur immediately after a
network failover.
Limiting the registration rate protects the RP control plane from being overwhelmed during
significant multicast state churn. Remember, that multicast state churn can be a consequence of
something happening in both the multicast overlay or the underlying unicast network. Table 5-17
displays the commands used to limit the rate of RP registrations.

Table 5-17 RP Group Register Rate-Limiting Commands

The number to which register packets should be limited depends largely on the number of potential
sources registering at the same time and their data rates. Determining a baseline for multicast
applications provides the administrator a general idea of what the communication characteristics look
like. A typical setting in a PIM sparse-mode (PIM-SM) network is between 4 and 10 messages per
second.
In an Auto-RP environment, you can use this feature in your design to filter certain RPs for certain
multicast groups. This is needed if you have unique requirements to split the multicast groups aligned
to each RP. This is achieved by using the command ip pim rp-announce-filter rp-list access-list
group-list access-list . This is normally configured at the mapping agent for Auto-RP. Table 5-18
displays the commands used to configure RP announce filters for mapping agents.

Table 5-18 RP Announce Filter Commands

 Finally, the commands listed for IOS/XE and NX-OS in Table 5-18 allow an RP to filter RP group
mapping announcements. This allows an administrator to control domain learning from the Auto-RP
mapping agent. IOS-XR does not support this command because it is now assumed that domains will
have sufficient controls in place, prior to mapping agent dynamics.
Best Practice and Security Summary
The last several sections provide many solutions to protect the multicast control plane and
ultimately the integrity of the entire network. Determining the appropriate solution depends on the
landscape of the network infrastructure, the capabilities of the organization managing the solution, and
the risk you are willing to take. Table 5-19 provides an overview of the different solutions.
 Table 5-19 Summary of Basic Multicast Deployment Recommendations
Putting It All Together
Let’s go back and take a look at our example company, Multicaster’s Bank Corp. Figure 5-17
illustrates the high-level topology for the Multicaster’s Bank Corp. network. This scenario is a good
example to bring all the concepts about configuring PIM together.
 Figure 5-17 Multicaster’s Bank Corp. Network
Scenario: Multicaster’s Bank Corp. Media Services
Multicaster’s Bank Corp.’s marketing department has decided to make some upgrades to the way
they manage their brand locally at the Los Angeles HQ, New York City HQ, and Boca Raton regional
offices. The HQ campuses share a very similar design, and the company wishes to deploy localized
digital signage to each campus, giving media control to the local marketing teams. They purchased a
digital signage media engine for each HQ office. They have also purchased a new webcasting TV
system for internal management communications to employees (IPTV) that will be used corporate-
wide. As new products are announced, the IPTV service can update employees with important
messages about product changes.
In this scenario, we work for the director of infrastructure. The marketing department has given her
some high-level requirements about the two systems. In addition, she is concerned that adding a lot of
unicast media traffic to the campus LAN could impact daily operations at all three buildings. Both the
digital signage and IPTV servers support multicast, and she has asked us to look over the
requirements and make the engineering and configuration recommendation to meet the requirements
using multicast.
Requirements:
There will be 20 unique feeds of IPTV media so individual departments can select between
different services or advertisements from the service.
Each of the HQ campuses should have the ability to support up to eight unique streams.
The initial media systems will not be built with redundancy until Phase Two. However, this is a
business-critical application for marketing; thus, the infrastructure supporting both systems should be
as dynamic, reliable, and as redundant as possible.
Because these systems are an integral part of the company’s branding, they should be made as
secure as possible network-wide.
Each of the HQ digital signage systems should be separate from each other and no streams should
appear at the Boca Raton office. There should be no chance that signage media can leak from one
campus to another.
All workstations across the campus should be able to tap into the IPTV feed. The IPTV server
will be located at the Boca Raton office, where the principal IT is located. The location of the IPTV
server is shown at a high-level in Figure 5-18 . Figure 5-19 shows the NYC HQ office network with
the digital signage media server connected. The LA campus has an identical configuration to that of
the NYC campus.
Note
Not all service providers offer the same services when it comes to multicast. One SP may not
allow native multicast over the MPLS links, whereas another may. Some SPs may limit multicast
traffic by default. It is important for enterprise customers to work with their service providers to
determine which services are available, the fees that may apply (if any), and how services may affect
a given design.
Figure 5-18 Multicaster’s Boca Raton Office
 Figure 5-19 NYC Office
In addition to these requirements, our director has reminded us of a few technical details relevant
to enabling multicast:
A single MPLS cloud, obtained through a national service provider, connects the three corporate
campuses. Each of the three campuses has two routers, each with one link to the provider, as shown in
Figure 5-20 .
 Figure 5-20 Multicaster’s MPLS WAN Cloud
The MPLS service provider supports full PIM sparse-mode multicast over the MPLS backbone,
and the provider uses Cisco edge routers. The six Multicaster’s routers each have an EIGRP neighbor
relationship with the MPLS cloud.
The service provider has an enforced multicast state limit of 24 entries per customer. (This
depends on the service-level agreement that the enterprise has with the service provider.) Any entries
forwarded beyond this state limit will not be installed on the provider routers.
Because firewalls are not yet in the path of the media servers, network security has recommended
that multicast filtering be used to ensure that group state can be formed where only appropriate and
that IGMP be locked down on gateway routers.
The IPTV server and the two digital signage media servers only support IGMPv2.
Network configurations should always be identical (with the exception of IP addresses) between
the two HQ campuses. This creates network operations consistency. To ease stream identification,
however, each HQ campus should use different multicast group addresses between the eight streams
in each campus.
Using this information, we should be able to derive an appropriate multicast design and
configuration that will suit Multicaster’s needs. It is clear from the requirements that multiple
overlapping domains will provide the separation needed between the local media engines and the
IPTV service. There should be one corporate-wide domain that can encompass IPTV and reach all IP
phones in the three campus networks. In addition, the digital signage streams will be best localized if
a single overlapping domain is created for each HQ location (NYC and LA respectively). We will
propose dividing the network into the three domains shown in Figure 5-21 .

Figure 5-21 Overlapping PIM Domains

Domains should be segmented and secured using appropriate filters at the edge of each domain.
Because the servers do not support IGMPv3, we will not be able to use SSM; consequently, sparse-
mode PIM is our best option. To achieve dynamic ASM state consistency and reliability, we should
use a dynamic RP feature in combination with Anycast RP redundancy within each domain. Auto-RP
will be a good choice to provide our dynamic RP-mapping mechanism.
All routers and switches fall within the larger corporate domain. The WAN routers R1 and R3
connecting to the MPLS cloud will provide the Anycast RP and Auto-RP candidate and mapping agent
functions for the corporate domain. Figure 5-22 shows the high-level design for this configuration,
with R1 and R3 acting as both Anycast peers and RP candidates. The primary loopback (Loopback0)
interfaces on R1 and R3 will act as redundant mapping agents.
 Figure 5-22 Multicaster’s Global Domain
To support the local HQ domains, we will propose using Anycast RP and Auto-RP; ensuring
network operations consistency. Because these domains are much smaller, we will consolidate RP-
candidate and mapping agent functions onto the same devices. Campus Layer 3 core switches C3 and
C4 will act as the RPs for these domains. The core switches should also be the boundary of the local
domain. Because both the LA and NYC campuses have identical configurations, we can use the same
design for both. Figure 5-23 shows the proposed high-level design for the NYC campus domain.
 Figure 5-23 NYC Office RP Configuration
Let us examine the configuration steps on the network routers and switches to enable PIM across
the network.
All routers and Layer 3 core switches:
Step 1. Enable multicast routing globally using the ip multicast-routing command.
Step 2. Enable PIM on all interfaces in the multicast distribution path, including interfaces facing
either sources or receivers.
Step 3. Enable PIM on all relevant loopback interfaces (this step is critical for future configuration
steps).
Step 4. Enable ip pim auto-rp listener on all multicast-enabled routers.
Step 5. Ensure that PIM is disabled on all other interfaces not in the forwarding path, in particular
on any interfaces that face external entities, including VPN or other tunnel interfaces, and on Internet-
facing interfaces.
Step 6. If required by security policy, manually lock down PIM neighbor relationships on PIM
interfaces using the ip pim neighbor filter command, especially on those interfaces connecting to the
MPLS service provider.
Step 7. Use an ACL denying all PIM and all multicast for any of the interfaces identified in Step 5.
Step 8. Tune all unicast routing for fast convergence, if applicable to the infrastructure and
application (not a requirement for multicast), and turn on multipath multicast when and where it is
warranted.
All Layer 2 switches:
Step 1. Enable PIM on any Layer 3 interfaces facing sources or receivers, including switch virtual
interface (SVI) interfaces.
Step 2. Ensure that IGMP snooping is enabled.
Step 3. Tune STP to ensure maximum convergence and forwarding efficiency throughout the Layer
2 domain.
When the network is up and PIM is communicating across the network, it is time to create the
address schemas that will be used for each application and domain. Remember that the requirements
ask for the same addresses to be used in both NYC and LA. Because both the IPTV and digital
signage applications are private ASM, we will use the 239.0.0.0 group address block to assign the
groups. Our addressing requirements are very small. We can allow the second octet in the block to
indicate the scope of the domain (global or local), the third octet to indicate the application type, and
the fourth octet to indicate the stream number. If we use .10 and .20 to represent global and local
scopes respectively, while using .1 to represent the IPTV application and .2 the digital signage
streams, the group schema would look like the one shown in Figure 5-24 .
 Figure 5-24 Multicast Address Schema
Next, we need to create the RPs, segment the domains, and secure the borders. We also need to set
up Auto-RP boundaries for the network using a scope. Let us start with the global, IPTV domain. The
following configuration steps should be taken on routers R1–R4 to create the Anycast RPs and Auto-
RP mappings required for all L3 devices.
Routers R1 and R3 (global RPs):
Step 1. Create an Anycast RP loopback interface with and identical address on each router. (In this
case, we can use Loopback 100 with IP address 192.168.254.250, making sure the interface is PIM
sparse-mode–enabled.)
Step 2. Establish Anycast MSDP peering between routers R1 and R3 using the main loopback
(Looback0) interface as the peering sources. Loopback 0 should also be configured as the router-id.
Step 3. Configure the new interface as the Auto-RP candidate using a scope that covers the
maximum breadth (in hop count) of the service provider network and Multicaster’s routers.
Step 4. Create and apply an accept-register filter that limits multicast group registrations to only
those in the global group address schema (deny the NYC and LA local groups).
Step 5. Ensure that the new loopback (Loopback 100) is distributed into the EIGRP routing unicast
routing domain.
All downstream routers:
Step 1. Configure Loopback0 on R2 and R4 as Auto-RP mapping agents using a scope that covers
the maximum breadth of the service provider network and Multicaster’s routers.
Step 2. Configure all edge gateway routers with an IGMP accept-list limited to only those groups
included in the group schema.
Step 3. Create and apply a multicast boundary list on every Layer 3 device/interface that makes up
the edge of the multicast network, such as Internet-facing interfaces (not shown in the diagrams).
Step 4. Use ACLs on the service provider facing interfaces to limit IP multicast packets to only
those groups specified in the schema.
In the preceding configuration, interface Loopback 0 is the primary EIGRP and router management
loopback on each router. We used Interface Loopback 100 on R1 and R3 with address
192.168.254.250/32 as the Anycast RP address. A network statement is added to EIGRP to
propagate this address to the rest of the network. Remember that the network routers will build the
shared tree to the closest unicast RP, meaning the routers will perform a L3 recursive look-up on the
RP address, and whichever path has the shortest distance will be used as the RPF path. Auto-RP also
uses this loopback address as the Candidate RP, giving us a hybrid RP design.
We need to make similar configuration changes for the local HQ domains (Local RPs). Here we
show only the NYC domain configuration steps for brevity.
Step 1. On NYC3 and NYC4 L3 switches, create a new loopback interface (in this case, we will
use Loopback200 on each), enabling PIM sparse-mode and assigning IP address 172.30.254.245.
Step 2. Establish Anycast MSDP peering between the primary loopback (Loopback0) interfaces on
both routers.
Step 3. Configure the new loopback, Loopback 200, as both Auto-RP candidate and Auto-RP
mapping agent with scope 2 on NYC3 and NYC4.
Step 4. Boundary router: It is recommended to filter Auto-RP on the boundary routers to prevent
local scope leakage. The TTL (Auto-RP scope) value should be one more than the one configured on
the candidate RP or mapping agent. This configuration prevents announce and discovery messages
from leaking from the local site.
We would repeat these steps exactly in the LA local domain. However, in this scenario, we want
the LA and NYC local domains to be identical, including the group addresses. Keep in mind that the
larger Layer 3 unicast network will end up having multiple routes for all the Anycast peers. What
would happen if we use the same loopback IP addresses for the Anycast RPs in both domains?
Note
All Layer 3 devices will use the unicast RIB entry for the loopback to build the RPF neighbor
relationship. EIGRP will calculate a path to each Anycast loopback, as well as a feasible successor
for each. EIGRP will select the path with the lowest metric to place in the RIB. Because it is a very
large unicast domain, EIGRP would have a path to all four Anycast RPs with the same IP address (C3
and C4 in both the NYC and LA domains). To further ensure domain isolation, it is recommended to
use different IP addresses for the Anycast loopbacks in the NYC and LA domains (the local admin
scoped domains); one address for LA and one address for NYC. An alternative would be to use
distribute lists to control Layer 3 unicast updates, but many might consider this the more difficult
option. To have complete control over the domain, use boundary best practices previously discussed.
When all of these configuration tasks are complete, the domains should be operational and isolated.
Further security and domain configuration is likely warranted. We would use the preceding sections
and other published configuration guides to derive the appropriate additional configurations for each
PIM router in the network. Ultimately, we need to ensure the RPs are protected, and that the mapping
process on all routers is limited to those groups explicitly configured. Other security measures should
be based on an individual organization’s policy and therefore is not included in this scenario.
Summary
This chapter discussed the importance of creating a functional schema for IP multicast addressing,
how this schema provides better control over security implementations and builds a foundation to
easily manage applications by establishing location and application identity into the address of the
multicast messages.
Design elements were considered on the proper placement and implementation strategies using
active/active and active/standby, and the different solutions using Auto-RP, BSR, static, Anycast, and
MSDP mesh groups.
We generally desire the traffic flow in a unicast network and the multicast overlay to be congruent,
but there are additional considerations for multicast that need to be addressed when equal-cost
multipath unicast routes are involved. These include load-sharing using multipath selection, static
entries, and BGP.
Security has been a growing concern over the years, and increasing the footprint of the
infrastructure by adding multicast capability adds to the challenge. Fortunately, several mechanisms
are available to protect the control plane and data plane for multicast. Some of these include control-
plane protection, multicast filtering, and scoping.
Chapter 6. IPv6 Multicast Networks
Chapter 6. IPv6 Multicast Networks
This chapter begins by covering the fundamentals of IPv6 and why there is such a great need for it
today. It explains IPv6 multicast group addressing, along with the concept of scoping and IPv6
multicast group address assignments. You also learn how IPv6 multicast addresses are mapped to
MAC addresses. We discuss the Layer 2 and Layer 3 multicast environment, how subscriptions to
multicast streams are controlled, how IPv6 multicast messages are routed across the network, and the
different options for configuring a rendezvous point. Included in this chapter are many configuration
examples to get you started on the road to implementing IPv6 multicast.
IPv6 Fundamentals: A Quick Overview
The rapid growth of the Internet has caused the depletion of IPv4 address space. Consequently,
IPv6 is taking hold to provide for the expansion of the Internet and our ability to access any device on
the planet.
IPv4 addresses use 32 bits for a numerical value to distinguish individual devices, whereas IPv6
uses 128 bits. This increase offers tremendous scalability. The implementation of IPv6 has another
interesting characteristic in that there is no longer support for traditional network broadcasts. The two
methods of communication available with IPv6 are unicast or multicast. Because multicast was
considered during the creation of the protocol, some inherent capabilities improve that operation.
Besides the greater amount of address space, the rendezvous point (RP) address and scoping
information can be embedded in the message.
The biggest difference between IPv4 and IPv6 is the size of the IP address. An IPv6 address has
128 bits (16 bytes). These 128 bits are divided into 8 16-bit hexadecimal blocks separated by colons
(:) in the format: X:X:X:X:X:X:X:X. Two examples of IPv6 addresses are as follows:
2002:8888:9999:AAAA:BBBB:CCCC:DDDD:1234
2002:8888:0:0:0:0:0:AAAA
An IPv6 address like the one above, 2002:8888:0:0:0:0:0:AAAA, can contain consecutive zeroes
within the address. Two colons (::) within the address can be used to represent a group of
consecutive zeroes. The two-colon marker can occur at the beginning, middle, or end of an IPv6
address, but it can only occur once within the entire address, representing the longest set of
consecutive zeros. Table 6-1 shows a list of compressed format IPv6 addresses.

Table 6-1 Compressed IPv6 Address Formats

Just as with IPv4, an IPv6 unicast address is an identifier for a single host interface on a single
networked device. It is a logical address that represents a physical location. A packet that is sent to a
unicast destination address is routed and ultimately forwarded to the physical interface identified by
that address. Unlike IPv4, IPv6 has different types of unicast addresses, and they serve different
functions. The two most important to this text are global (often referred to as aggregatable global )
addresses and link-local addresses.
A global unicast address is similar to a typical IPv4 address. Its structure enables address
supernetting and subnetting and ultimately the strict aggregation of routed prefixes in the global
(Internet) IPv6 table. Global addresses are assigned throughout a network and eventually are
aggregated upward through organizations. Eventually, an aggregated block or blocks of address space
are advertised by the organization to the Internet service providers (ISPs). These addresses are
public and are assigned by IANA just like their IPv4 counterparts.
Global IPv6 addresses are defined by a global routing prefix, a subnet ID, and an interface ID.
Except for addresses that start with binary 000, all global unicast addresses have a 64-bit interface
ID. Thus, the global address has essentially two major sections, a 64-bit network prefix (equivalent
to a major class network with the ability to subnet) and a 64-bit host identifier. This makes the
assignment of addresses much easier for network administrators.
The assignable range of addresses for each 64-bit prefix is enormous, creating millions of potential
networks with millions of potential hosts. This solves for the problem of address depletion in IPv4
networks. Additional subnetting can encroach on the 64-bit host ID of the address as well. This
enables the address to convey not only the subnet but also any potential scoping included by the
administrator. The final 48-bits in the address for many IPv6 hosts might simply be the MAC address
of the host interface where the address is applied, connecting physical and logical in a single field.
The IPv6 global unicast address allocation uses the range of addresses that start with binary value
001 (2000::/3). Figure 6-1 shows the structure of an aggregatable global address.

Figure 6-1 IPv6 Address Format with Global Unicast Addressing

Note
We have only provided here a very brief overview of IPv6, but this is enough to get us moving
forward on IPv6 multicast. If you need additional information on IPv6, we suggest you seek
additional Cisco publications specific to the subject.
The other type of addresses that we are concerned with are known as link-local addresses . A link-
local address is an IPv6 unicast address that is typically automatically configured on any IPv6
interface. Consequently, if you configure a global address on a Cisco router interface, the router will
by default, also assign a link-local IPv6 address. According to RFC 4291, link-local addresses must
begin with the prefix FE80::/10 (1111 1110 1000 0000) and end with interface identifier in the
modified EUI-64 format (normally automatically assigned using the physical address of the interface;
Media Access Control [MAC] addresses in the case of Ethernet).
Link-local addresses are an absolute requirement for any IPv6 deployment. They are used in the
IPv6 Neighbor Discovery Protocol (NDP), many infrastructure protocols, and the unique IPv6
stateless auto-configuration process. Nodes on a local link can use link-local addresses to
communicate. This is very important to understand, IPv6 nodes do not need globally unique addresses
to communicate.
Also of significance, is that IPv6 routers cannot forward packets that have link-local source or
destination addresses to other links. The name link-local implies its scope. This scope is
automatically enforced by any operating system that is conforming to IETF specifications for IPv6
address scoping (this should be universal). Link-local addresses are intended for local host-to-host
communication only. Automatic assignment of these addresses can obscure implementations,
especially inside the network infrastructure. Fortunately, the administrator can assign more meaning to
the address by statically changing link-local addresses on Cisco routers and switches. Figure 6-2
shows link-local address format.

Figure 6-2 Link-local Address Format

We felt that a quick introduction to IPv6 addressing was important to exploring IPv6 multicast. Of
course, anyone who has studied IPv6 can tell you from a protocol perspective, there is a lot more
going on than just updating the size of IP addresses. Many parts of protocol intercommunication have
also evolved with the addressing capabilities. Of course, multicast is no different.
IPv6 Layer 3 Multicast Group Addressing
As with IPv4 multicast addressing, IPv6 addressing is defined by the IETF. RFC 2373 and RFC
4291 specifically outline the foundations of IPv6 multicast group addressing, including how they are
scoped. Scoping is an important part of IPv6 theory and consequently is an integral part of IPv6
addresses, which we will discuss.
The basic purpose of the address has not changed. The IPv6 multicast address still identifies a
group of subscribing nodes, and a node may belong to any number of groups. Because of the
differences in address size and scope, IPv6 multicast group addresses have a unique format. Figure 6-
3 illustrates the IPv6 group address format as defined by RFC 2373 and updated by RFC 4291.
 Figure 6-3 IPv6 Multicast Group Address Format
The list that follows describes the fields shown in Figure 6-3 :
11111111: All group addresses must begin with this bit pattern.
Flags: There are four one-bit fields equaling four flags that can be set, 0RPT. Flag values are:
The first (highest order bit) flag is reserved and thus always set to 0.
If the T bit is set to 0, this indicates a permanently assigned (“well-known”) multicast address,
assigned by the Internet Assigned Numbers Authority (IANA).
When the T bit is set to 1, this indicates a non-permanently assigned (“transient” or
“dynamically” assigned) multicast address.
The P flag is defined by RFC 3306:
If the P-bit = 0, this indicates a multicast address that is not assigned based on the network prefix.
If the P-bit = 1, this indicates a multicast address that is assigned based on the network prefix.
When P = 1, T must also be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of
[ADDRARCH] in RFC 3306.
The R flag is defined by RFC3956 and used in defining embedded RP addresses, an IPv6
inherent method for dynamically updating RP mappings on downstream routers without the use of a
secondary distribution protocol like BSR or Auto-RP. Embedded RP is discussed in subsequent
sections of this chapter.
Scope: A four-bit field used to indicate the scope (breadth of forwarding) of the group. Scope
values are:
0000 – 0: reserved
0001 – 1: node-local scope
0010 – 2: link-local scope
0011 – 3: (unassigned)
0100 – 4: (unassigned)
0101 – 5: site-local scope
0110 – 6: (unassigned)
0111 – 7: (unassigned)
1000 – 8: organization-local scope
1001 – 9: (unassigned)
1010 – A: (unassigned)
1011 – B: (unassigned)
1100 – C: (unassigned)
 1101 – D: (unassigned)
1110 – E: global scope
1111 – F: reserved
Group ID : Assigned by administrator and identifies the group as either permanent or transient
within the given scope.
The scope value, however, does not indicate the meaning of the group address, only the scope in
which the group should be found. Any non-permanently assigned group address is meaningful only in
the scope that precedes it. The same address may appear in multiple physical locations in the
network, but need not interfere with each other, or indicate any membership beyond the local network.
For example, if a group of servers is assigned a permanent multicast address with a group ID of 111
(in hexadecimal), then:
FF01:0:0:0:0:0:0:111 is destined for all servers on the same node as the sender, and only that
sender.
FF02:0:0:0:0:0:0:111 is destined for all servers on the same link as the sender, and only that
sender.
FF05:0:0:0:0:0:0:111 is destined for all servers at the same site as the sender, and only that sender.
FF0E:0:0:0:0:0:0:111 is destined for all servers in the Internet.
Why is this relevant? Remember our discussion about overlapping domains in Chapter 5 ,
especially the domain design and addressing schema for Multicaster’s Bank Corp.? If IPv4
addressing had a similar scoping mechanism, the design and schema could be simplified. In addition,
scopes can be nested within each other. Figure 6-4 is a good way to visualize this relationship.

Figure 6-4 Nested Group Scoping

Furthermore, IANA breaks scope for group address assignments down into two types:
Variable-scope Group Addresses: These addresses are similar across all scopes but represent
distinct groups. Variable scope addresses are reserved for certain types of services or applications.
For example, Network Time Protocol (NTP), which has a multicast address of
FF0X:0:0:0:0:0:0:101, where X masks the address scope.
Fixed-scope Group Addresses: These group addresses have a certain meaning only within the
scope they are defined in. Fixed-scope addresses should not be changed. This type of address is
important in the basic operation of IPv6. For this reason, a few common addresses are listed in Table
6-2 .

Table 6-2 Fixed-Scope IPv6 Multicast Addresses

Note
According to RFC 2373, the source addresses in IPv6 packets cannot be multicast addresses, nor
can a multicast address appear in any routing header.
IPv6 Multicast Group Address Assignments
IPv6 RFC 2373 also details a predefined and well-known set of multicast groups. These group
addresses are reserved and may not be assigned to any public or private group, other than those
expressed by the RFC.
The reserved multicast addresses are as follows:
FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
 FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
Other groups with the scopes listed above can be assigned to make a unique group. For example,
the All-Nodes IPv6 multicast group addresses are as follows:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
The All-Nodes group starting with FF01 represents an all nodes (all IPv6 addressed interfaces on
this node, or node-local) group. The All-Nodes group starting with FF02 represents a link-local
nodes group (the nodes on a particular subnet).
Another reserved group, the All-Routers group, could be any of the following group addresses:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2
There is a breakdown for these groups as well. Each group address above identifies a specific set
of all IPv6 routers within scope 1 (node-local), 2 (link-local), or 5 (site-local).
There are many other reserved addresses, and there is an order to the assignment of group
addresses for public and private use within the various scopes as defined earlier. One example to pay
special attention to is the solicited-node group address of FF02:0:0:0:0:1:FFXX:XXXX.
A solicited-node multicast address is made from the low-order 24-bits of a reserved address
(unicast or Anycast) in combination with appended prefix bits to the prefix
FF02:0:0:0:0:1:FF00::/104. The resulting range of solicited-node group multicast addresses is
FF02:0:0:0:0:1:FF00:0000–FF02:0:0:0:0:1:FFFF:FFFF. Therefore, the solicited-node multicast
group address that corresponds to the IPv6 address 4037::01:800:200E:8C6C is
FF02::1:FF0E:8C6C. An IPv6 node is required (due to the solicited nature) to join and process any
associated solicited-node group addresses derived from the unicast or Anycast addresses assigned to
its interfaces. This is a convenient way of targeting a specific group of nodes in a specific network or
subnet; it’s similar to a directed broadcast but with a different purpose.
For all other multicast address assignments, the IPv6 multicast group assignment uses the low-
order 32-bits of the IPv6 address to create a MAC address. This is to avoid the MAC layer address
overlap problem experienced in IPv4, which was discussed in the Chapter 2 .
New IPv6 multicast addresses should be assigned so that the group identifier is always in the low-
order 32 bits, as shown in Figure 6-5 .
 Figure 6-5 IPv6 Multicast Address Format with MAC
Any other restricted or public group assignments are managed by IANA.
IANA Unicast-Prefix–Based Multicast Address
IANA controls global IPv6 group address assignments for any organizations that apply. These are
most often organizations that have Internet presence and are assigned individual autonomous system
numbers (ASN). In IPv4, IANA uses GLOP addresses to make these types of public assignments,
which includes the ASN’s assigned BGP AS number in the group. For IPv4 networks this is the type
of group assignment that could be made dynamic, such that the IANA assigned prefix can be used for
routing group packets across the Internet to the appropriate organization.
Because IPv6 does not have a GLOP equivalent, the IANA assigned unicast prefix for the
organization can be used to make the global group assignment instead. The resulting address is a
unique unicast-prefix–based multicast group address block, as defined by RFC 3306. The address
provides a way to dynamically assign IPv6 group numbers and also allows organizations to assign
private address space, including those who do not have global ASNs, or who receive address
assignments from service providers.
In these addresses, the 64 bits provided for the Unicast-Prefix field are sufficient based on the
structure of the IPv6 unicast addresses (64 bits are used by the interface ID). The format presented in
Figure 6-6 illustrates how any given IPv6 unicast prefix can become a multicast address, with 232
possible groups per unicast prefix. The reserved bits must still always be set to 0, and the unicast
prefix will follow. Thus, the address will always start with FF3X:. If an organization was assigned
the IPv6 prefix 3F7E:FFFF:1/48, the resulting assignable group block would be
F3X:0030:3F7E:FFFF:0001::/96. This gives each organization a unique, private block of group
addresses with which to work. It is important to remember that the scope of the unicast-prefix–based
multicast address should not exceed that of the embedded unicast prefix.
 Figure 6-6 Unicast-Prefix–Based Group Addressing
IPv6 Source-Specific Addressing
IPv6 source-specific multicast (SSM) group addresses make use of the penultimate four bits of the
first hextet (the flag field) and the unicast-prefix–based address assignment rule. IPv6 SSM addresses
use a 3 (decimal, or 0011 in binary) as a flag to indicate SSM compatibility. The group addresses
used in an SSM deployment model are defined as a subset of the unicast-prefix–based multicast
addresses, where the Prefix Length and the Unicast-Prefix fields are set to 0. Figure 6-7 illustrates
how SSM addresses are derived.

Figure 6-7 IPv6 SSM Addressing

Solicited-Node Multicast Addresses
In addition to these group assignments, IPv6 multicast also incorporates the concept of solicitation
. Address solicitation occurs when a unicast host sends out a request for a link-local IPv6 group
address derived from the local host unicast network. The scope of the request is link-local and is
typically used only for control plane functionality. The request derives and generates a multicast
prefix for each unicast and IPv6 Anycast prefix assigned to the network.
The solicited-node group address format is FF02::1:FF00:0000/104, where the low-order 24 bits
are the same as the unicast or Anycast address that generated it. The derived group address represents
a deterministic way to identify the local-link multicast group(s) to which an IPv6 unicast address host
is listening. Thus, if all the requisite host information needed to establish unicast connectivity (the
MAC address, and so on) is not available, the destination can still be reached via multicast sent to its
solicited-node multicast address.
IPv6 Address Scoping and Schema Considerations
IPv6 addressing has clear advantages over its IPv4 counterpart when it comes to schema design.
With multicast addressing, the biggest advantage is the size of the group portion of the address: 112
bits in length (more than four and a half times the size of the configurable portion of an IPv4 group
address). In addition, masking on each hex character in the address is simple. This makes creating a
unique schema much simpler.
Administrators should also create an organizational address schema for IPv6 multicast group
assignments. Wildcard masks serve an identical function for IPv6 addressing. Any meaningful split in
the group address section of the address is appropriate.
At press time, most of the Internet still uses IPv4. In fact, few global multicast applications
currently use IPv6 multicast. However, with the exponential growth of mobile computing, this is
likely to change quickly in the coming years. Mobile computing and the Internet of Everything will
require significantly more addressing than IPv4 can provide, and multicast resource efficiency will
become a de facto requirement for many applications.
This also means that dynamic and temporary group address assignments may become more
commonplace. The IETF has developed an addressing methodology to meet this objective. This
methodology is defined in RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses .
Architects and administrators who are creating an IPv6 group address schema should thoroughly
understand RFC 3307. Architects should also consider IETF RFC 3956 (updated by RFC 7371),
which describes embedding the rendezvous point (RP) address in an IPv6 multicast address, when
creating an IPv6 group address schema. Implementing RFC 3956 can greatly simplify multicast
domain boundaries.
Multicast-IPv6-Address-to-MAC-Address Mapping
Like IPv4 multicast addresses, IPv6 group addresses must be mapped into the MAC sublayer for
Ethernet transport. Remember, the underlying Layer 2 technology has not changed. Switches will still
need to create or segment forwarding domains, flooding domains, and broadcast domains. Obviously,
with the expanded address size, this cannot happen with multicast the same way we did it for IPv4.
Does more address space mean more binary math? Fortunately not! Converting an IPv6 multicast
address to a multicast MAC is much easier using IPv6, although there is far greater overlap of IPv6
addresses to MAC addresses. The addresses in the organizationally unique identifier (OUI) reserved
block for IPv6 multicast MAC addresses are from 0X3333.0000.0000 to 0X3333.FFFF.FFFF.
To map the IPv6 multicast of FF02:0:0:0:0:0:E040:0707 to a MAC multicast, the low-order 32-
bits of the IPv6 address are concatenated with the high-order bits of 0X3333, as shown in Figure 6-8
.
 Figure 6-8 IPv6-Multicast-Group-Address-to-MAC-Address Conversion
As you can see, this is much easier than converting IPv4 multicast. It also makes for much cleaner
multicast topologies. What IPv6 adds in address complexity, it makes up for with simplicity in the
network design, or at least that is the intention.
IPv6 Layer 2 and Layer 3 Multicast
In order to establish appropriate and efficient IPv6 multicast communication, both the switching
and routing environments must be configured appropriately. Layer 2 devices use Multicast Listener
Discovery (MLD) protocol to configure the infrastructure so that it sends multicast messages to the
appropriate devices. PIM6 is used at Layer 3, and the components you learned from IPv4 still apply.
Multicast Listener Discovery for IPv6
Through the use of Multicast Listener Discovery (MLD) protocol, IPv6 routers discover on a
network the multicast devices that are requesting a multicast stream(s). In other words, the purpose of
MLD is to serve as the group subscription method for local segments, in much the same way IGMP
provides subscription services to IPv4 hosts and gateways. There are currently two versions of MLD,
version 1 and version 2. MLDv1 is the IPv4 equivalent to IGMPv2 and MLDv2 is equivalent to
IGMPv3. The IGMP message format was discussed earlier in Chapter 3 .
MLD is built on standard Internet Control Messaging Protocol (ICMP), the same protocol that
enables traceroute, ping, and echo replies. MLD leverages ICMP messages to carry information about
group subscription. This is very unlike IGMP, which has its own messaging format and process. In
spite of this difference, both IGMP and MLD provide networks with a way to automatically control
and limit the flow of multicast traffic. This control is achieved through the use of special multicast
queriers. Queriers and hosts do not perform the same functions. Let us quickly review the role of
each:
 A querier is usually a network device, such as a gateway multicast router, that sends query
messages to discover which network devices are members of a given multicast group. Queries can be
specific to a group (“Are there any listeners for group G on the segment?”), or they can be general (as
in, “Are there any listeners for any groups on this segment?”).
A host is simply a receiver, which can also be routers or other network devices. Hosts send
group report messages to inform the querier of group subscriptions.
MLDv1
MLDv1 was originally defined by RFC 2710 and updated by RFCs 3590 and 3810. MLDv1 has
functions similar to IGMPv2 and consequently has similar messages and message formats. Figure 6-9
shows the packet header format for MLD messages.

Figure 6-9 MLD Message Format

Note
Because MLD is built on ICMP, the packet header is the same as ICMP and the Type field is used
to distinguish the packet as an MLD message. The code field for an MLD message is always set to 0.
Outside of the Multicast Address field, the most important field in the header is the Type field. The
type in the message header indicates what type of message is being issued:
Multicast Listener Query: As previously mentioned, there are two types of queries, both
designed to locate multicast hosts on a segment. General queries are sent to the link-local, all-nodes
multicast address of FF02::1. The MLD Multicast Address field is set to groups unspecified (::),
which should solicit a group report (called a listener report) response from each receiver. A group-
specific query is used to identify the listeners for a given group that is listed in the MLD Multicast
Address field of the message and is sent to the queried multicast address.
MLD queries use a Maximum Response Delay field. This is the maximum allowed delay (in
milliseconds) in which a node has to send a report if it has a listener. In all other MLD messages, this
field is not used and is therefore set to 0. The Multicast Listener Query message uses a message
header Type field equal to 130 (0X82).
Multicast Listener Report: Hosts use the report message type as a response to an MLD query.
The destination group address for a report is the multicast address being reported about. In report and
done messages, the Multicast Address field contains the multicast group to which a member listens or
the group it is leaving. The Multicast Listener Report message uses a message header Type field
equal to 131 (0X83).
 Multicast Listener Done: This message is sent by a node to indicate that it stopped listening to a
multicast address. It is the equivalent of an IPv4 IGMP leave group message. The destination group
address for a done message is the link-local, all-routers multicast address (FF02::2). It is assumed
that the local multicast querier will receive this message, which is also the likely Layer 3 gateway.
The Multicast Listener Done message uses a message header Type field equal to 132 (0X84).
Note
All MLD packets are sent with a link-local address as the IPv6 source address. The packet time-
to-live (TTL) is set to 1. This is done to ensure the packet is not routed outside of the segment. MLD
reports must be sent with a valid IPv6 link-local source address. If the sending interface has not yet
acquired a valid link-local address, the unspecified group (::) source address is used. Sending this
type of report with an unspecified address is allowed to support the use of IPv6 multicast in the
Neighbor Discovery Protocol.
MLDv2
MLD is defined by RFC 3810, and like IPv4 IGMPv3, is designed to improve upon the efficiency
of group subscription messaging. It also supports source specific group reports and requests making it
capable of supporting SSM, just like the IPv4 counterpart. Outside of these improvements, the
message types and formats for MLDv2 are identical to MLDv1 with one notable exception: MLDv2
does not use Listener Done messages.
The biggest difference between the versions is the way MLDv2 improves the Listener Report
message. Rather than sending a response for each group, it concatenates a set of records, each record
containing information that relates to multicast group address subscriptions. This provides MLDv2
Report messages the capability of leaving a group, thereby eliminating the need for the MLDv1 Done
message.
MLDv2 is backward compatible with MLDv1 and can coexist comfortably in the same LAN as
MLDv1-only hosts. Keep in mind that when a host using MLD version 1 sends a Done message, the
querier router needs to send query messages to reconfirm that this host was the last MLD version 1
host joined to the group before it can stop forwarding traffic, and this process takes about two
seconds. This is known as leave latency and is also present in IPv4 IGMP version 2–enabled
networks.
Configuring MLD and the MLD Message Process
We will use the same network in Figure 6-10 to explain the mechanics of MLD and MLD
configuration. In this case, the sender, Sender-1, sends multicast traffic to IPv6 multicast address
FF37::7. The receiver, Receiver-1, requests the multicast stream.
 Figure 6-10 MLD Example Network
The prerequisite for configuring IPv6 multicast routing requires IPv6 unicast routing to be properly
configured and running. Here, we provide the basic MLD configuration, but unicast routing is beyond
the scope of this book.
Begin by configuring the router for IPv6 unicast routing in global configuration mode, as shown in
the list that follows. In this example, we use IOS-XE. Refer to the command references for other
operating systems.
Step 1. Enable IPv6 unicast routing:
Click here to view code image
R1(config)#ipv6 unicast-routing
Step 2. Assign IPv6 address to the appropriate interfaces in interface configuration mode, for
example:
Click here to view code image
R1(config-if)#ipv6 address 2001:192:168:7::1/64
Step 3. Configure the IGP of your choice. You are on your own for this one!
R1(config)#router ?
 Step 4. Enable IPv6 multicast routing in global configuration mode. By default, this enables PIM
and MLD on any interfaces configured with an IPv6 address.
Click here to view code image
R1(config)#ipv6 multicast-routing
To ease the configuration burden for IPv6, it is assumed that MLD should be enabled on all IPv6-
enabled interfaces when ipv6 multicast-routing is configured. In addition, many of the same
configuration options that are available for IGMPv1-3 are also available for MLD, in particular those
configurations that affect MLD on the segment. Examples include joining groups, limiting group
addresses that are accepted in a response by ACL, and other query timers/parameters.
The configuration in Example 6-1 shows some of the MLD commands as they would be applied in
an IOS-XE router’s running configuration file.
Example 6-1 MLD Interface Commands
Click here to view code image
!
interface GigabitEthernet0/0
ipv6 enable
ipv6 mld join-group FF37::1 [include | exclude]
ipv6 mld static-group FF37::1 [include | exclude]
ipv6 mld access-group <access-list-name>
ipv6 mld query-timeout <seconds>
ipv6 mld query-interval <seconds>
ipv6 mld query-max-response-time <seconds>
!
Note
The include and exclude for the join-group and static-group commands are used to limit message
processing by the gateway router (likely the querier). The include parameter allows the administrator
to set specific groups for which messages will be received, excluding all others (whitelisting). The
exclude parameter enforces the opposite logic, specifying addresses to exclude messages from, and
accepting all others (blacklisting).
Multicast Listener Discovery Joining a Group and Forwarding Traffic
The list that follows outlines the high-level steps involved for the host to begin receiving the
multicast stream.
1. The host (Receiver-1) sends a multicast join message to the group address FF37::7 in this
example. Below is a packet capture of the message. There are a few items to note: The destination
address for a MLDv2 report messages is FF02::16, and this corresponds to the MAC address of
33:33:00:00:00:16. The IPv6 address of Receiver-1 that sources the messages is a link-local address
because it starts with FE80:
Click here to view code image
Ethernet II, Src: 80:ee:73:07:7b:61, Dst: 33:33:00:00:00:16
Destination: 33:33:00:00:00:16
Address: 33:33:00:00:00:16
 .... ..1. .... .... .... .... = LG bit: Locally administered address
(this is NOT the factory default)
.... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast)
Source: 80:ee:73:07:7b:61
Address: 80:ee:73:07:7b:61
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::82ee:73ff:fe7:7b61 Dst: ff02::16
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 36
Next header: IPv6 hop-by-hop option (0)
Hop limit: 1
Source: fe80::82ee:73ff:fe07:7b61
[Source SA MAC: 80:ee:73:07:7b:61]
Destination: ff02::16
Hop-by-Hop Option
Next header: ICMPv6 (58)
Length: 0 (8 bytes)
IPv6 Option (Router Alert)
Type: Router Alert (5)
Length: 2
Router Alert: MLD (0)
IPv6 Option (PadN)
Type: PadN (1)
Length: 0
PadN: <MISSING>
Internet Control Message Protocol v6
Type: Multicast Listener Report Message v2 (143)
Code: 0
Checksum: 0xfec7 [correct]
Reserved: 0000
Number of Multicast Address Records: 1
Multicast Address Record Changed to exclude: ff37::7
Record Type: Changed to exclude (4)
Aux Data Len: 0
Number of Sources: 0
Multicast Address: ff37::7
2. The router receives the report from Receiver-1. The following command verifies the entry:
Click here to view code image
 ASR1K-2#show ipv6 mld groups FF37::7 detail
Interface: GigabitEthernet0/0/0
Group: FF37::7
Uptime: 00:05:10
Router mode: EXCLUDE (Expires: 00:03:55)
Host mode: INCLUDE
Last reporter: FE80::82EE:73FF:FE07:7B61
Source list is empty
3. The (*,G) entry and (S,G) entries are added to the multicast routing table, which can be seen
using the following command:
Click here to view code image
ASR1K-2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF05::1:3), 00:18:27/never, RP 2001:192:168::1, flags: SCLJ
Incoming interface: GigabitEthernet0/0/1
RPF nbr: FE80::D68C:B5FF:FE43:1E01
Immediate Outgoing interface list:
GigabitEthernet0/0/0, Forward, 00:18:27/never
(*, FF37::7), 00:04:04/never, RP 2001:192:168::1, flags: SCJ
Incoming interface: GigabitEthernet0/0/1
RPF nbr: FE80::D68C:B5FF:FE43:1E01
Immediate Outgoing interface list:
GigabitEthernet0/0/0, Forward, 00:04:04/never
(2001:192:168:8::10, FF37::7), 00:01:34/00:01:55, flags: SJT
Incoming interface: GigabitEthernet0/0/1
RPF nbr: FE80::D68C:B5FF:FE43:1E01
Inherited Outgoing interface list:
GigabitEthernet0/0/0, Forward, 00:04:04/never
4. The router performs an RPF check and updates the Multicast Forwarding Information Base
(MFIB) table with the outgoing interface; this is where Receiver-1 is located and where the outbound
interface list (OIF) is added.
The following output displays the IPv6 MFIB table for the multicast address of FF37::7. The
Hardware (HW) forwarding entry indicates that traffic is flowing:
Click here to view code image
ASR1K-2#show ipv6 mfib FF37::7 verbose
Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,
 ET - Data Rate Exceeds Threshold, K - Keepalive
DDE - Data Driven Event, HW - Hardware Installed
I/O Item Flags: IC - Internal Copy, NP - Not platform switched,
NS - Negate Signalling, SP - Signal Present,
A - Accept, F - Forward, RA - MRIB Accept, RF - MRIB Forward,
MA - MFIB Accept
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second
Other counts: Total/RPF failed/Other drops
I/O Item Counts: FS Pkt Count/PS Pkt Count
Default
(*,FF37::7) Flags: C K HW
0x9E OIF-IC count: 0, OIF-A count: 1
SW Forwarding: 0/0/0/0, Other: 0/0/0
HW Forwarding: 48/0/1390/0, Other: 0/0/0
GigabitEthernet0/0/1 Flags: RA A MA NS
GigabitEthernet0/0/0 Flags: RF F NS
CEF: Adjacency with MAC: 33330000000700225561250086DD
Pkts: 0/0
(2001:192:168:8::10,FF37::7) Flags: K HW DDE
0x9F OIF-IC count: 0, OIF-A count: 1
SW Forwarding: 0/0/0/0, Other: 0/0/0
HW Forwarding: 61559/278/1390/3018, Other: 0/0/0
GigabitEthernet0/0/1 Flags: RA A MA
GigabitEthernet0/0/0 Flags: RF F NS
CEF: Adjacency with MAC: 33330000000700225561250086DD
Pkts: 0/0
Leaving a MLD Group
When Receiver-1 is no longer interested in the multicast traffic, a MLD report message is sent to
be removed from the group, as depicted in the packet capture in Example 6-2 .
Example 6-2 MLD Leave Group Message Received
Click here to view code image
Ethernet II, Src: 80:ee:73:07:7b:61, Dst: 33:33:00:00:00:16
Destination: 33:33:00:00:00:16
Source: 80:ee:73:07:7b:61
Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::82ee:73ff:fe07:7b61, Dst: ff02::16
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000
.... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000
Payload length: 36
Next header: IPv6 hop-by-hop option (0)
Hop limit: 1
Source: fe80::82ee:73ff:fe07:7b61
Destination: ff02::16
Hop-by-Hop Option
Next header: ICMPv6 (58)
Length: 0 (8 bytes)
IPv6 Option (Router Alert)
IPv6 Option (PadN)
Internet Control Message Protocol v6
Type: Multicast Listener Report Message v2 (143)
Code: 0
Checksum: 0xffc7 [correct]
Reserved: 0000
Number of Multicast Address Records: 1
Multicast Address Record Changed to include: ff37::7
Record Type: Changed to include (3)
Aux Data Len: 0
Number of Sources: 0
Multicast Address: ff37::7
Multicast Listener Discovery (MLD) Snooping
MLD snooping for IPv6 works in much the same way as IGMP snooping for IPv4. The overall
objective is to minimize the delivery of multicast traffic to devices that are not interested in receiving
it on a common Layer 2 flooding domain. Remember, MLDv1 is the IPv4 equivalent to IGMPv2, and
MLDv2 is equivalent to IGMPv3.
Note
MLDv1 and MLDv2 are product- and software-specific; please refer to product documentation to
determine support.
Let us examine MLD snooping configuration and mechanics. As shown in Figure 6-11 , Host A and
Host B are receiving an IPv6 multicast stream from FF02::E040:707.
 Figure 6-11 MLD Snooping Example
Configuring MLD Snooping
The first step in configuring MLD snooping is to make sure your switch supports IPv6 MLD. Some
switches support MLD enablement out of the box. Other switches might need to have IPv6-switching
capabilities added. For example, some older IOS switches use a switch database management (SDM)
template to allocate switching resources to various protocols. If SDM templates are used, you can see
the template assignment by issuing the show sdm prefer command, as demonstrated in Example 6-3 .
Example 6-3 Verifying IPv6 MLD Support
Click here to view code image
Switch#show sdm prefer
The current template is "desktop IPv4 and IPv6 routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.
number of unicast mac addresses: 1.5K
number of IPv4 IGMP groups + multicast routes: 1K
 number of IPv4 unicast routes: 2.75K
number of directly-connected IPv4 hosts: 1.5K
number of indirect IPv4 routes: 1.25K
number of IPv6 multicast groups: 1K
number of directly-connected IPv6 addresses: 1.5K
number of indirect IPv6 unicast routes: 1.25K
number of IPv4 policy based routing aces: 0.25K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 0.5K
number of IPv6 policy based routing aces: 0.25K
number of IPv6 qos aces: 0.5K
number of IPv6 security aces: 0.5K
The switch database management (SDM) templates allow you to change the behavior of the switch.
In order to support IPv6 multicast, you must select a template that supports IPv6. If your switch does
not support IPv6 multicast, you will need to change the template and reboot the switch, as
demonstrated in Example 6-4 .
Note
Always check the specifications, requirements, and limitations of your switching platform. Not all
platforms support every IPv6 feature.
Example 6-4 SDM Template for IPv6 and IPv4 Support
Click here to view code image
C3560E(config)#sdm prefer dual-ipv4-and-ipv6 routing
Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.
Now that IPv6 is enabled, you can complete the remainder of the configuration. Enable IPv6 MLD
using the following command:
Click here to view code image
C3560E(config)#ipv6 mld snooping
Using the show ipv6 mld snooping mrouter command, you can verify the attached router has been
detected as demonstrated in Example 6-5 .
Example 6-5 Show ipv6 mld snooping mrouter Command Output
Click here to view code image
C3560E#show ipv6 mld snooping mrouter
Vlan ports
---- -----
12 Gi0/13(dynamic)
The output in Example 6-6 shows Host A connected to Gi0/3 and Host B connected to Gi0/5, and
both are accessing the FF02::E040:707 multicast stream.
Example 6-6 Show MLD Snooping Per VLAN
Click here to view code image
 C3560E#show ipv6 mld snooping address vlan 12
Vlan Group Type Version Port List
-----------------------------------------------------------------------
12 FF02::E040:707 mld v2 Gi0/3, Gi0/5,
Gi0/13
The debug ipv6 mld provides a great deal of information. The following output shows the MLD
report from Host B:
Click here to view code image
MLDSN: Processing v2 Report as a MLDv1 Report for group FF02::E040:707 on port
Gi0/5 in vlan 12
When Host B leaves the multicast group, the following debug message is displayed:
Click here to view code image
MLDSN: Processing v2 Report as MLDv1 Leave for group FF02::E040:707 on port Gi0/5
in vlan 12
IPv6 Layer 3 Multicast and Protocol Independent Multicast 6 (PIM6)
It’s important to remember that although some of the protocols and rules have changed, and the
addresses have changed between IP versions 4 and 6, for the most part it is all just Internet Protocol
(IP). That means the PIM rules and features that apply to IPv4 multicast also apply to IPv6 multicast.
We discussed how MLD replaces IGMP in the IPv6 network. For PIM, the other important multicast
infrastructure protocol, the IETF drafted new PIMv2 rules to handle IPv6 addresses and packets but
essentially left PIMv2 intact.
The important aspect to remember is that no new multicast routing protocol is required. When we
use PIM in an IPv6 network, with IPv6 rules enabled, we sometimes call it PIM6. This is not a new
protocol or protocol version, but again, indicates IPv6 support in PIMv2 implementations. This
allows both IPv4 and IPv6 to reside simultaneously on the same infrastructure while still supporting
multicast for each.
To illustrate this point, we take a look at some of the same output we examined in earlier chapters
regarding how basic Layer 3 multicast operations work. In this case, we use a new IPv6 network
without IPv4-enabled, running PIM sparse-mode (PIM-SM) on Cisco IOS-XE. We keep the network
very simple, with only three routers (R1–R3), as shown in Figure 6-12 . R1 is the RP and is using
BSR to advertise itself. R3 Loopback 0 has joined two IPv6 multicast groups, FF05::1 and FF06::1.
 Figure 6-12 Example IPv6 Multicast Network
Now, let us examine the multicast state table on R2, where the forwarding path and the reverse path
converge. For IPv4 we would use the command show ip mroute to see the IPv4 multicast state table.
To collect the equivalent IPv6 output, we need only replace ip with ipv6 . The command is show ipv6
mroute , as demonstrated in Example 6-7 .
Example 6-7 Displaying the IPv6 Multicast State Table
Click here to view code image
R2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(2002:11:1:1::1, FF35::1), 00:36:40/00:02:47, flags: ST
Incoming interface: Ethernet0/0
RPF nbr: FE80::A8BB:CCFF:FE00:100
Immediate Outgoing interface list:
Ethernet1/0, Forward, 00:36:40/00:02:47
(2002:11:1:1::1, FF36::1), 00:46:23/00:02:47, flags: STI
Incoming interface: Ethernet0/0
RPF nbr: FE80::A8BB:CCFF:FE00:100
Immediate Outgoing interface list:
Ethernet1/0, Forward, 00:36:40/00:02:47
The command output is essentially identical to the IPv4 output. First we are given the table flags
indicating the PIM type and other tree information. The protocol and state flags should be very
familiar because they are the same as those in IPv4. Next, we are given the states of the two (S,G)
entries for groups FF05::1 and FF06::1. Notice how the state information in the output includes the
RPF neighbor information as well as the outgoing interface list (OIL).
What might strike some administrators as odd is the RPF neighbor information. Take a closer look
at the output for the (2002:11:1:1::1, FF35::1) state entry, paying attention to the highlighted portions.
The OIL and the RPF neighbor in this case are IPv6. However, the process for determining this
information is the same as the process for IPv4. The only difference is that the IPv6 routing table
(RIB) and forwarding table (FIB) are used to derive the OIL and RPF check information and populate
the v6 MRIB and MFIB respectively. The source, 2002:11:1:1::1 in the (S,G) for each entry, is the
loopback for R1.
If we show the RPF information for the source address on R2, using the show ipv6 rpf command
(again, same command, just replace ip with ipv6 ), we see that the unicast address 2002:11:1:1::1 is
in fact located out router interface Ethernet0/0, but that the RPF neighbor address is not the configured
interface address of R1 located out E0/0, as shown in Example 6-8 .
Example 6-8 RPF for IPv6 Multicast
 Click here to view code image
R2#show ipv6 rpf 2002:11:1:1::1
RPF information for 2002:11:1:1::1
RPF interface: Ethernet0/0
RPF neighbor: FE80::A8BB:CCFF:FE00:100
RPF route/mask: 2002:11:1:1::1/128
RPF type: Unicast
RPF recursion count: 0
Metric preference: 120
Metric: 2
Instead, the RPF address is the link-local address configured for R1’s E0/0 interface. The IPv6
unicast route table (RIB) and CEF table (FIB) show us where this RPF information was derived
from, by using the show ipv6 route and show ipv6 cef commands, as shown in Example 6-9 .
Example 6-9 IPv6 RIB and FIB
Click here to view code image
R2#show ipv6 route
IPv6 Routing Table - default - 9 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1
I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
EX - EIGRP external, ND - Neighbor Discovery
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
R 2002:11:1:1::1/128 [120/2]
via FE80::A8BB:CCFF:FE00:100, Ethernet0/0
R2#show ipv6 cef
2002:11:1:1::1/128
nexthop FE80::A8BB:CCFF:FE00:100 Ethernet0/0
FF00::/8
multicast
As you can see, the nexthop information for the RPF check uses the link-local address of the
neighboring router (R1) from the RIB and FIB as the forwarding address. That makes the link-local
address of R1 the RPF neighbor, even though the global routes are learned via the configured global
interface addresses (the RPF route from the show ipv6 rpf output). This is a function of IPv6
addressing rules, and it may require that you spend some time double-checking local connectivity in
an IPv6 PIM domain.
You can also see that many protocols, including PIM, use the link-local addresses to form neighbor
adjacencies and exchange protocol information. Look at the show ipv6 pim neighbor command on R2
in Example 6-10 . Here we find the neighbor relationships are established between the link-local
addresses of the routers.
Example 6-10 IPv6 PIM Neighbors Table
Click here to view code image
 R2#show ipv6 pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, G - GenID Capable
Neighbor Address Interface Uptime Expires Mode DR pri
FE80::A8BB:CCFF:FE00:100 Ethernet0/0 00:46:37 00:01:16 B G 1
FE80::A8BB:CCFF:FE00:301 Ethernet1/0 00:36:52 00:01:33 B G DR 1
We can see that R1, located out Ethernet0/0 has a link-local address of
FE80::A8BB:CCFF:FE00:100, the same as that found in the RPF information. To find the link-local
address of a given interface—in this case, Ethernet0/0 on R1—simply use the show ipv6 interface
[type (port/slot) ] command. If we issue this command, show ipv6 interface Ethernet0/0 on R1, we
find consistency with the table outputs from R2, as demonstrated in Example 6-11 .
Example 6-11 Finding the Link-Local Address
Click here to view code image
R1#show ipv6 interface e0/0
Ethernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::A8BB:CCFF:FE00:100
No Virtual link-local address(es):
Global unicast address(es):
2002:10:1:1::1, subnet is 2002:10:1:1::/64
Joined group address(es):
FF02::1
FF02::2
FF02::9
FF02::D
FF02::16
FF02::1:FF00:1
FF02::1:FF00:100
FF06::1
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
Output features: MFIB Adjacency
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 42613)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
The important component to understand is that the IPv6 RIB and FIB are used for RPF loop
prevention and state population in the MRIB and MFIB of the router. This is the same process as the
one used for IPv4, and it is consistent with the rules of PIMv2 as laid out by IETF RFCs. Almost any
command that you can issue for IPv4 multicast you can issue for IPv6 multicast. Most of the
commands simply require a change in the syntax from ip to ipv6 . This is true even of configuration
commands in IOS.
Let us look at the basic PIM and interface configuration of R1 in Example 6-12 to illustrate this
point more fully.
Example 6-12 R1 PIM and Interface Configuration
Click here to view code image
hostname R1
!
!
ip cef
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Loopback100
no ip address
ipv6 address 2002:100:1:1::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::1/64
ipv6 enable
ipv6 router isis TEST
!
!
router isis TEST
net 49.0001.0000.0001.00
!
!
ipv6 pim bsr candidate bsr 2002:11:1:1::1
ipv6 pim bsr candidate rp 2002:11:1:1::1 group-list ACL priority 190
!
!
!
ipv6 access-list ACL
permit ipv6 any FF05::/64
In this configuration, we enabled PIM on the relevant interfaces (Ethernet0/0, Loopback0, and
Looback100) by simply enabling ipv6 multicast routing , as previously mentioned. The show
running-config all command (see Example 6-13 ), shows us that this automatically configures PIM-
SM for IPv6 using the command ipv6 pim sparse-mode , along with many other IPv6 multicast
commands, as shown here for interface Ethernet0/0. (Remember that sparse-mode with or without
SSM support is the only option for PIM6, and consequently the command to enable it per interface is
simply ipv6 pim .)
Example 6-13 Finding Automatic PIM Configuration for IPv6
Click here to view code image
R1#show running-config all
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::1/64
ipv6 enable
ipv6 nd reachable-time 0
ipv6 nd ns-interval 0
ipv6 nd dad attempts 1
ipv6 nd prefix framed-ipv6-prefix
ipv6 nd nud igp
ipv6 nd ra lifetime 1800
ipv6 nd ra interval 200
ipv6 redirects
ipv6 unreachables
ipv6 mfib forwarding input
ipv6 mfib forwarding output
ipv6 mfib cef input
ipv6 mfib cef output
ipv6 mld query-max-response-time 10
ipv6 mld query-timeout 255
ipv6 mld query-interval 125
ipv6 mld router
ipv6 pim hello-interval 30
ipv6 pim dr-priority 1
ipv6 pim join-prune-interval 60
ipv6 pim
ipv6 router isis TEST
!
Note
Once again, enabling IPv6 multicast in IOS/XE is rudimentary. Unlike IPv4 multicast configuration,
when the ipv6 multicast-routing command is issued, all IPv6 configured interfaces on the router are
automatically enabled for PIM6; no other configuration is necessary. The ipv6 pim command is
enabled on the interface and does not appear in the interface configuration. To disable PIM on a
particular interface, use the command no ipv6 pim . For routers and switches running NX-OS, you
must configure PIM6 on each interface, but only after the PIM6 and PIM features are enabled using
the commands feature pim and feature pim6 . In IOS-XR PIM6 can be enabled globally or on an
individual interface basis using the router pim configuration mode, the same as with IPv4, but using
the address-family ipv6 command option. For all operating systems, a PIM6-enabled interface
always operates in sparse-mode (dense-mode operation is not supported). IOS-XR PIM6 features are
all configured in a similar manner, under the router pim and address-family configuration sub-
modes.
In addition, we have enabled PIM BSR for IPv6. This was accomplished using the same command
as BSR for IPv4 (ip pim bsr candidate bsr address ), except we replace the ip syntax with ipv6 .
This makes configuring IPv6 multicast a cinch, and it enables dual stack networking (running IPv4 and
IPv6 natively over the same infrastructure) with ease. IPv4 multicast configuration complexities and
interface mode management confusion have been eliminated in PIM6.
PIM6 Static mroute Entries
Traffic engineering is also a feature of PIM6. IPv6 static state entries (mroutes) behave in a similar
manner to IPv4 static mroutes. IPv6 static mroutes share the same database as IPv6 static routes and
are implemented by extending static route support. This is very different from the way static mroutes
are configured. Static mroute entries support equal-cost multipath routing for multicast forwarding, as
well as unicast forwarding.
Static mroutes for IPv6 multicast are configured as an extension of IPv6 static routes. An IPv6
static route can be configured for unicast routing only, static multicast route for multicast RPF
selection only, or to use a static route for both unicast routing and multicast RPF selection. This is
accomplished using the command ipv6 route address/mask interface-type slot/port [multicast |
unicast ]. If no keyword (multicast or unicast) is specified in the IPv6 static route, it is used for both
unicast routing and multicast RPF selection.
The following is an example configuration for adding a static entry on R2 for RPF of source
2001:DDBB:200::10/128.
Click here to view code image
!
ipv6 route 2001:DDBB:200::10/128 Ethernet0/1 [multicast | unicast ]
!
Both IPv6 multipath-multicast and tunneling are supported on all Cisco platforms. These can come
in very handy for v6 installs, for the same reasons they do for IPv4 networks. Tunneling can also be
especially useful for crossing a non-PIM6 or non-IPV6-enabled boundary. This is common in some
IPv6 networks, where IPv6 is deployed at the edge but tunneled over an IPv4 core network. In these
situations, there are ways to propagate the multicast information from IPv6 across the IPv4
infrastructure, but many may find it easier to simply configure IPv6-enabled tunnels, where
appropriate.
In addition to static entries for tunneling and multipath routing, IPv6 MP-BGP address-family
information (AFI) can be used for PIM6 traffic engineering. Multicast BGP with the IPv6 multicast
address family provides multicast BGP extensions for IPv6 and supports the same features and
functionality as IPv4 BGP. IPv6 enhancements to multicast BGP include support for an IPv6 multicast
address family, network layer reachability information (NLRI), and next-hop (the next router in the
path to the destination) attributes that use IPv6 addresses. A subsequent address family identifier
(SAFI) provides information about the type of network layer reachability information that is carried
in the attribute. Multiprotocol BGP unicast uses SAFI 1 messages, and multiprotocol BGP multicast
uses SAFI 2 messages.
The IPv6 multicast address family can carry routes used for RPF lookup by the IPv6 PIM protocol,
and multicast BGP IPv6. Users must use IPv6 multicast BGP AFI when using IPv6 multicast with
BGP because the IPv6 unicast BGP learned routes will not be used for IPv6 multicast RPF. A
separate BGP routing table is maintained to configure incongruent policies and topologies (for
example, IPv6 unicast and multicast) by using IPv6 multicast RPF lookup. Multicast RPF lookup is
very similar to the IP unicast route lookup.
PIM6 Group Modes
In Cisco IOS Software, each IP multicast group operates in exactly one mode of PIM:
General any-source multicast (ASM): The group ranges specified in Generic Multicast Group
Addresses Definition and Unicast-Prefix–Based Addresses will by default always be handled as
sparse-mode groups. If Cisco IOS Software is not aware of an RP for a group, then a default group
mode is used (sparse-mode for IPv6, for example).
Source-specific multicast (SSM): The SSM group range (SSM address range) is hard-coded
and will always be handled in the SSM mode (no wildcard joins processed, no RP definition for the
group range required).
Embedded RP groups: Embedded group ranges (embedded RP addresses) cannot be predefined
(the RP address is not preliminarily known) in the SSM sense, but the router interprets the embedded
RP group address only when the first PIM joins for that group appear or the first data appears from
the directly connected source; prior to that, it is not possible to determine any RP for the group.
Embedded RP is explained in the next section, but it is introduced here to complete the group mode
discussion.
The group mode can be displayed using the show ipv6 pim range-list command (PIM range for an
output example). By default, when multicast routing is enabled, the group modes are listed in Table 6-
3.

Table 6-3 IPv6 Group Modes

PIM6 RP Options
One element where there is less similarity between IPv4 PIM and PIM6 are the options that exist
for configuring RPs in ASM mode. As shown in the previous network, PIM6 supports BSR. It also
supports static RP configurations as well as the use of Anycast RP. The configurations for these are
nearly identical to the configurations for IPv4 (as we showed with BSR RP).
However, the IETF developed a new, open standard method of embedding RP information within
multicast packets as an easier alternative for performing dynamic group mappings. This is known as
embedded RP and is defined by IETF RFC 3956. Cisco did not extend proprietary Auto-RP support
to PIM6. Consequently, there is no support for Auto-RP in an IPv6 multicast network. Table 6-4
provides you a complete overview of the available methods to configure RP group mappings, with a
comparison between IPv4 and IPv6 PIM.

Table 6-4 PIM RP Options Compared

As shown in Table 6-4 , if the domain is not using embedded RP, BSR is the only other dynamic RP
propagation and mapping option. Again, there is no Auto-RP support for IPv6. PIM6 devices in a
domain must still be able to map each multicast group to the correct RP address regardless of IP
version. With the PIM6 BSR feature, multicast routing devices will detect an unreachable RP. Any
mapping tables will be modified after the failure so that the unreachable RP is no longer used. If
failover is configured within the BSR domain using priority, new tables will be rapidly distributed
throughout the domain when the primary RP failure has fully converged.
As shown earlier, the configuration for BSR is nearly identical to IPv4, changing only the key
syntax word ip to ipv6 . The domain still needs at least one of each, a candidate RP and a candidate
BSR, configured in the domain. The PIM BSR messages are propagated through the network in the
same way, except using the link-local IPv6 PIM connection instead of the IPv4 PIM network.
Just as with IPv4 PIM, PIM6 sparse-mode multicast groups need to associate with the IP or IPv6
address of an RP. If the domain is running dual-stack (simultaneous configuration of IPv4 and IPv6)
an IPv4 RP can work as the RP for PIM6 managed groups. This is one of the big advantages of the
IETF using the same PIM version (version 2) for both IPv4 and IPv6. When a new IPv6 multicast
source starts sending multicast packets, its local gateway router DR encapsulates these data packets
in a PIM register message and sends them to the RP for that multicast group. When a new multicast
receiver joins a group, the local gateway DR sends a PIM join message to the RP for that multicast
group. This functionality does not change, and the role of the RP is the same as it is for IPv4.
Don’t forget the best practice and security recommendations for PIM domains that we discussed in
the previous chapter. These all still apply for PIM6 domains. It is especially important to limit the
scope of the PIM6 domain. When using BSR, for example, make sure you have a well-defined BSR
borders using the ipv6 pim bsr border command and well-defined domain boundaries using the ipv6
multicast boundary command.
PIM6 Anycast RP
IPv6 PIM supports Anycast services for PIM-SM RP in the same manner that IPv4 PIM does with
one major difference: There is no MSDP or equivalent protocol for IPv6, and therefore it cannot be
used in PIM6 Anycast RP. This also means that Anycast RP can only be used inside a domain that runs
PIM only and cannot be propagated beyond a domain border or boundary. Outside of MSDP, the other
principles of Anycast RP from IPv4 PIM still apply. It allows receivers and sources to rendezvous to
the closest RP. Packets from a source must be replicated by the receiving RP to all other RPs to find
joined receivers and reliably create both the shared tree and source tree. The unicast RP address can
still be configured statically on each router or distributed using a dynamic protocol to all PIM6
devices throughout the domain. The mechanics of Anycast RP for PIM6 are the same as those
introduced for IPv4 in Chapter 4 based on RFC 4610.
Remember that Anycast RP offers the PIM domain robust RP services along with fast convergence
when a PIM RP device fails. This is considered ideal for any IPv6 multicast services that are mission
critical or of high importance to the organization where PIM6 is deployed. Let us examine the IOS-
XE configuration for PIM6 Anycast RP. It is of course very similar to the non-MSDP configuration
option for IPv4 and works using the same principles.
In this configuration example, we use the same three router network we used for the previous BSR
configuration example. R1 still acts as an RP, but R3 will also be added to the RP set using Anycast
RP global-scope address 2002:F:F:F::1/128 (Loopback 500 on each RP router). All routers
(including the RP) will be configured with a static RP address command. Examine Figure 6-13 to see
how this configuration is arranged.

Figure 6-13 PIM6 Anycast RP Example

Note
Normally, in a network of this small size, Anycast RP would not be recommended. We are using a
three-node network to simplify the configurations for demonstration. Anycast RP is ideal for large
multicast domains in which reliability and fast convergence are a must.
Example 6-14 shows the router configurations used to support this Anycast RP deployment.
Example 6-14 Configuration to Support Anycast RP Deployment
 Click here to view code image
RP: R1
hostname R1
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Loopback500
no ip address
ipv6 address 2002:F:F:F::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::1/64
ipv6 enable
ipv6 router isis TEST
!
router isis TEST
net 49.0001.0000.0001.00
!
ipv6 pim anycast-rp 2002:F:F:F::1 2002:11:1:1::3
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
permit ipv6 any FF05::/64
RP: R2
hostname R2
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::2/128
 ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::2/64
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet1/0
no ip address
ipv6 address 2002:10:1:2::1/64
ipv6 enable
ipv6 router isis TEST
!
router isis TEST
net 49.0002.0000.0002.00
!
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
permit ipv6 any FF05::/64
R3
hostname R3
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::3/128
ipv6 enable
ipv6 router isis TEST
!
interface Loopback500
no ip address
ipv6 address 2002:F:F:F::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet1/0
no ip address
ipv6 address 2002:10:1:2::2/64
ipv6 enable
 ipv6 router isis TEST
!
router isis TEST
net 49.0002.0000.0003.00
!
ipv6 pim anycast-rp 2002:F:F:F::1 2002:11:1:1::1
ipv6 pim rp-address 2002:F:F:F::1 group-list ACL
!
ipv6 access-list ACL
permit ipv6 any FF05::/64
!
Embedded RP
Embedded RP defines an IPv6-unique address allocation policy in which the address of the RP is
encoded in an IPv6 unicast-prefix–based group address. This deployment greatly simplifies intra-
domain multicast designs, configurations, and operations. The rules for embedded RP are really quite
simple.
RFC3956 specifies rendezvous point (RP) address encoding and is accomplished by adding a new
field for the RP address and by defining a new flag in the Flgs field. The group address should start
with FF7X::/12, where the flag value of 7 means embedded RP. Figure 6-14 illustrates the format of
the group.

Figure 6-14 PIM6 Embedded RP Group Encoding Format

Elements in Figure 6-14 related to PIM6 Embedded RP:
Binary Bits: 11111111 at the start of the address identifies the address as being a multicast
address.
Flgs: The RFC redefines the four-bit “flag” field with the following option for using embedded
RP:
R = 1 indicates this is an embedded RP multicast address and contains the address of the PIM-SM
RP. When R = 1, P must be set to 1, and consequently T must also be set to 1, as specified in
RFC3306 (Generic Multicast Group Addresses Definition). This address range is therefore
represented as FF7X::/12 in the prefix format.
RIID: The RP address of the PIM-SM RP for this unicast-prefix–based multicast address.
Plen: The number of significant bits in the Network Prefix field.
 Network Prefix: Contains the assigned unicast network prefix. The maximum length is 64 bits.
Any unused prefix bits are not required to be zeroed anymore—a strict requirement from RFC 3306.
RFC 3956 relaxes this requirement. The “plen” is used to construct the RP address, but the group
address can contain a longer part of the unicast prefix.
Group ID: The address owner assigned 32-bit multicast group ID.
That means embedding an RP address in the multicast group is a simple operation. We need only
examine the Flgs, RIID, and Network Prefix fields for address derivation or loading. Figure 6-15
illustrates this process.

Figure 6-15 Deriving the RP Address from the Multicast Group Address
When using embedded RP, there is no need to configure routers with RP information or to use a
dynamic protocol to perform RP mapping and propagation. Instead, multicast-enabled devices can
extract and use the RP information from the group address, as shown above. That means a large
number of RPs can be deployed anywhere, either local to the PIM domain or on the Internet for inter-
domain multicast routing (multicast routing that typically occurs between two or more organizations
or the Internet). No additional protocol or PIM6 changes are required to support embedded RP, it is
built-in. Cisco router operating systems are programmed to automatically derive the RP information,
making additional configuration unnecessary.
Any routers acting as a physical RP for an embedded group must have a statically configured RP
address using an address assigned to one interface on the RP router. Routers automatically search for
embedded RP group addresses in MLD reports or PIM messages and data packets coming from the
source. When an embedded RP address is discovered, the router performs the group-to-RP mapping
using the newly learned RP address. If no physical RP exists that matches the learned address, or if
the learned RP address is not in the unicast RIB, then the router will not be able to complete the
multicast group state. Embedded RP does not allow administrators to escape the need for a physical
RP.
Also, keep in mind that a router can learn just one RP address for a multicast group using
embedded RP. That means that you cannot have redundancy with embedded RP, because you cannot
embed more than one RP address in the group. You can, however, use an Anycast RP set as the
physical RP component, so long as the derived embedded RP address always points to the Anycast
RP address configured on each router in the RP set. Also, as of this writing, embedded RP is not
compatible with bidirectional PIM.
 Let us adjust our BSR RP example (shown earlier in Figure 6-12 ) to include an embedded RP,
removing the BSR configuration and replacing it with a static RP configuration. Below are the
example configurations for each router. We statically configure our RP on R1 with a new
Loopback400 interface that is assigned the IP address 1234:5678:9ABC::1/128 from our example
group FF76:0150:1234:5678:9ABC::1234 (illustrated by Figure 6-15 ). On routers R2 and R3, we
can now remove any irrelevant RP information. In fact, outside of the command ipv6 multicast-
routing , no other multicast configuration is required on R2 and R3. We will, however, add an MLD
join on R3’s Loopback0 interface to simulate a host using the embedded RP group address from the
example above, group FF76:0150:1234:5678:9ABC::1234. Figure 6-16 depicts the updated
topology.

Figure 6-16 Embedded RP Example Configuration Topology

Example 6-15 shows the router configurations for embedded RP support.
Example 6-15 Configuration to Support Embedded RP
Click here to view code image
RP: R1
hostname R1
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Loopback400
no ip address
ipv6 address 1234:5678:9ABC::1
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::1/64
ipv6 enable
ipv6 router isis TEST
!
router isis TEST
net 49.0001.0000.0001.00
!
!
RP: R2
hostname R2
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::2/128
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/0
no ip address
ipv6 address 2002:10:1:1::2/64
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet1/0
no ip address
ipv6 address 2002:10:1:2::1/64
ipv6 enable
ipv6 router isis TEST
!
router isis TEST
net 49.0002.0000.0002.00
!
R3
hostname R3
!
ipv6 unicast-routing
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
no ip address
ipv6 address 2002:11:1:1::3/128
ipv6 enable
ipv6 router isis TEST
ipv6 mld join-group FF76:0150:1234:5678:9ABC::1234
!
interface Loopback500
no ip address
ipv6 address 2002:F:F:F::1/128
ipv6 enable
ipv6 router isis TEST
!
interface Ethernet0/1
no ip address
ipv6 address 2002:10:1:2::2/64
ipv6 enable
ipv6 router isis TEST
!
router isis TEST
net 49.0002.0000.0003.00
!
Look at what happens on R3 first. R3 needs to have an RP-to-group mapping for the joined group
of FF76:0150:1234:5678:9ABC::1234. Issuing a show ipv6 pim group-map on R3 reveals whether
this mapping has occurred, as in Example 6-16 .
Example 6-16 Verifying RP-to-Group Mapping
Click here to view code image
R3#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF76:150:1234:5678:9ABC::/112*
SM, RP: 1234:5678:9ABC::1
RPF: ,::
Info source: Embedded
Uptime: 00:12:32, Groups: 1
Great! The group is in fact learned by R3 through the MLD join and the router has derived the RP
1234:5678:9ABC::1 from the group. That’s good news. If the R1 RP is properly configured, we
should be able to reach R3. Because no packets have been sourced to the group address yet, R1
should not yet have a group mapping for FF76:0150:1234:5678:9ABC::1234, as shown by executing
the same show ipv6 pim group-map command on R1 in Example 6-17 .
Example 6-17 PIM6 Group Mappings
 Click here to view code image
R1#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF05::/64*
SM, RP: 2002:F:F:F::1
RPF: Tu2,2002:F:F:F::1 (us)
Info source: Static
Uptime: 00:37:08, Groups: 0
FF70::/15*
NO
Info source: Default
Uptime: 00:37:51, Groups: 0
If we now send an IPv6 ping packet sourced from interface Ethernet0/0 on router R1, the group
mapping should be derived from the embedded RP in the packet, and R1 should forward the packet
toward R3 with success, as in Example 6-18 .
Example 6-18 IPv6 Multicast Group Ping
Click here to view code image
R1#ping ipv6 FF76:0150:1234:5678:9ABC::1234
Output Interface: ethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF76:150:1234:5678:9ABC::1234, timeout is
2 ​seconds:
Packet sent with a source address of 2002:10:1:1::1
Reply to request 0 received from 2002:11:1:1::3, 39 ms
Reply to request 1 received from 2002:11:1:1::3, 1 ms
Reply to request 2 received from 2002:11:1:1::3, 1 ms
Reply to request 3 received from 2002:11:1:1::3, 1 ms
Reply to request 4 received from 2002:11:1:1::3, 1 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/39 ms
5 multicast replies and 0 errors.
Now, if we reissue the show ipv6 pim group-map command, we should find that R1, the RP, has
learned the group mapping and constructed the appropriate RPF neighbor, as demonstrated in
Example 6-19 .
Example 6-19 Source Added to PIM6 Group Mapping
Click here to view code image
R1#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF76:150:1234:5678:9ABC::/112*
SM, RP: 1234:5678:9ABC::1
RPF: Et0/0, FE80::A8BB:CCFF:FE00:200
 Info source: Embedded
Uptime: 00:00:26, Groups: 1
R2, the router between the source (R1) and the receiver (R3), needs to accept the incoming IPv6
multicast packet, derive the embedded RP information, create the appropriate group mappings and
state entries, and, finally, forward the packet down the OIL to R3. If we issue the show ipv6 pim
group-map and show ipv6 mroute commands on R2, we should see that this process is in fact
complete, as demonstrated in Example 6-20 .
Example 6-20 Final Group State in the MRIB
Click here to view code image
R2#show ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT, Y - Joined MDT-data group,
y - Sending to MDT-data group
g - BGP signal originated, G - BGP Signal received,
N - BGP Shared-Tree Prune received, n - BGP C-Mroute suppressed,
q - BGP Src-Active originated, Q - BGP Src-Active received
E - Extranet
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF76:150:1234:5678:9ABC::1234), 00:07:22/00:03:07, RP 1234:5678:9ABC::1,
flags: S
Incoming interface: Ethernet0/0
RPF nbr: FE80::A8BB:CCFF:FE00:100
Immediate Outgoing interface list:
Ethernet1/0, Forward, 00:07:22/00:03:07
R2#show ipv6 pim group-map
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF76:150:1234:5678:9ABC::/112*
SM, RP: 1234:5678:9ABC::1
RPF: Et0/0,FE80::A8BB:CCFF:FE00:100
Info source: Embedded
Uptime: 00:12:34, Groups: 1
As this example shows, configuring embedded RP for PIM6 is very easy. It is enabled by default.
R2 and R3 have virtually no PIM configuration requirements. Simply enable IPv6 multicast-routing
and you are off to the races.
Which brings us to one final consideration:
Any multicast host can embed an RP address, meaning host applications on multicast sources. That
means that if the embedded RP information is incorrectly configured by that application, the
infrastructure could have erroneous mappings for multicast groups. Embedded RP functionality is
enabled by default on all Cisco routers when IPv6 multicast routing is enabled. That can pose an
issue if the group has a large organizational scope. It also means that there is a chance that a low-end
router could end up becoming the RP for many of high data rate sources. If these are concerns in the
multicast domain, it may be best to use BSR and/or Anycast RP and to disable embedded RP
capability altogether.
Use the following IOS-XE command to disable embedded RP functionality:
Click here to view code image
no ipv6 pim [vrf vrf-name] rp embedded
Summary
Understanding the nuances of IPv6 and how to implement multicast is paramount given the
depletion of IPv4 address space and the number of devices that are being connected to the Internet.
One of the interesting aspects of IPv6 is the notion of a link-local address. These are intended for
local device-to-device communication only, and it must be well understood because the link-local
address is used for Neighbor Discovery Protocol (NDP), device communication, and so on.
Multicast Listener Discovery (MLD) protocol is used to discover devices requesting access to
multicast streams at Layer 2. There are currently two implementations of MLD, version 1 and version
2. Layer 2 switches use MLD to direct traffic to the appropriate destinations.
Previous knowledge of protocol independent multicast (PIM) for IPv4 networks makes it easy to
understand how PIM6 is implemented. Just as in IPv4, an additional routing protocol is not required
to implement PIM6. The PIM6 modes of operation include general any-source multicast (ASM),
source-specific multicast (SSM), and embedded RP groups.
Chapter 7. Operating and Troubleshooting IP Multicast Networks
Chapter 7. Operating and Troubleshooting IP Multicast Networks
This chapter covers the concepts of troubleshooting a multicast environment. We begin with an
overview of the logical steps in troubleshooting a multicast environment. Next, we use an example
network to explain the steps and commands necessary for troubleshooting in order to help you
understand multicast packet flows. This chapter also examines troubleshooting case scenarios that are
mapped to the multicast troubleshooting logic and the fundamental usage of that logic while
troubleshooting a multicast problem.
Multicast Troubleshooting Logic
There is a wide range of techniques to determine the root cause of a problem. In this chapter, we
take a systematic approach to troubleshooting multicast issues by using the following methodology:
1. Receiver check
2. Source check
3. State verification
Multicast Troubleshooting Methodology
The topology presented is a simple multicast network, as shown in Figure 7-1 . R3 and R4 are
configured as RP (with Anycast with Auto-RP for downstream propagation). OSPF is the routing
protocol configured for the unicast domain. R2 is the first-hop router that is connected to the source
and R5 is the last-hop router connected to the receiver.

Figure 7-1 Multicast Troubleshooting Sample Topology

Example 7-1 provides the configurations for the routers, and you should review these before
proceeding with the chapter.
Example 7-1 Show R3 and R4 Multicast Configurations for Sample Topology
Click here to view code image
R3
R3#show running-config
..
hostname R3
!
no ip domain lookup
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.3.3 255.255.255.255
ip pim sparse-mode
!
interface Loopback100
ip address 192.168.100.100 255.255.255.255
ip pim sparse-mode
!
interface Ethernet2/0
ip address 10.1.2.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet3/0
ip address 10.1.4.1 255.255.255.0
ip pim sparse-mode
!
router ospf 1
router-id 192.168.3.3
network 0.0.0.0 255.255.255.255 area 0
!
ip forward-protocol nd
!
ip pim autorp listener
ip pim send-rp-announce Loopback100 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback100 scope 20 interval 10
ip msdp peer 192.168.4.4 connect-source Loopback0
ip msdp cache-sa-state
ip msdp default-peer 192.168.4.4
!
access-list 1 permit 239.1.0.0 0.0.255.255
R4
R4#show running-config
Building configuration...
..
hostname R4
!
no ip domain lookup
ip multicast-routing
ip cef
!
interface Loopback0
 ip address 192.168.4.4 255.255.255.255
ip pim sparse-mode
!
interface Loopback100
ip address 192.168.100.100 255.255.255.255
ip pim sparse-mode
!
interface Ethernet2/0
ip address 10.1.5.1 255.255.255.0
ip pim sparse-mode
!
!
interface Ethernet3/0
ip address 10.1.4.2 255.255.255.0
ip pim sparse-mode
!
router ospf 1
router-id 192.168.4.4
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
ip pim send-rp-announce Loopback100 scope 20 group-list 1 interval 10
ip pim send-rp-discovery Loopback100 scope 20 interval 10
ip msdp peer 192.168.3.3 connect-source Loopback0
ip msdp cache-sa-state
ip msdp default-peer 192.168.3.3
!
access-list 1 permit 239.1.0.0 0.0.255.255
…
Example 7-2 provides the downstream router configuration.
Example 7-2 Downstream Router Configurations
Click here to view code image
R2
R2#show running-config
…
hostname R2
!
ip multicast-routing
ip cef
!
interface Loopback0
ip address 192.168.2.2 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 10.1.1.2 255.255.255.0
ip pim sparse-mode
load-interval 30
!
interface Ethernet1/0
ip address 10.1.3.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet2/0
ip address 10.1.2.1 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
….
R5
R5#show running-config
…
hostname R5
!
no ip domain lookup
ip multicast-routing
ip cef
interface Loopback0
ip address 192.168.5.5 255.255.255.255
ip pim sparse-mode
!
interface Ethernet0/0
ip address 10.1.6.1 255.255.255.0
ip pim sparse-mode
!
interface Ethernet1/0
ip address 10.1.3.2 255.255.255.0
ip pim sparse-mode
!
interface Ethernet2/0
ip address 10.1.5.2 255.255.255.0
ip pim sparse-mode
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
ip pim autorp listener
…
Baseline Check: Source and Receiver Verification
A baseline check is used to determine unicast connectivity between specific elements in the
network. Remember, multicast routing uses the unicast routing infrastructure. If unicast routing is not
working, neither will multicast!
Before starting the multicast baseline check, verify that the source and receiver have reachability.
This can be accomplished with a ping test.
To perform the baseline check and gather the baseline information, use the following steps:
Step 1. Receiver check: Make sure a receiver is subscribed via IGMP and that (*,G) to the RP
exists before trying to troubleshoot:
a. Check the group state on the last-hop router.
b. Check IGMP membership on the last-hop PIM-DR.
c. Verify the (*,G) state at the LHR and check the RP for the (*,G) entry and RPF.
Step 2. Source check: Make sure you have an active source before trying to troubleshoot:
a. Verify that the source is sending the multicast traffic to the first-hop router.
b. Confirm that the FHR has registered the group with the RP.
c. Determine that the RP is receiving the registry messages.
d. Confirm that the multicast state is built on the FHR.
Let’s perform each of the steps above on our sample network to ensure that the FHR and LHR are
operating as expected and that state for the flow is established between them. To do this, use the
following steps:
Step 1. Make sure a receiver is subscribed via IGMP before trying to debug:
a. Check the group state on the last-hop router.
Verify that the last-hop router (LHR) has the appropriate (*,G) entry:
Click here to view code image
R5#show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:02:35/00:02:50, RP 192.168.100.100, flags: SJCF
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:02:35/00:02:50
Notice that the incoming interface (IIF) is Ethernet2/0, and the outgoing interface is Ethernet0/0.
Referring to Figure 7-1 , we can see that this flow has been established using the proper interfaces.
b. Check IGMP membership on the last-hop PIM-DR:
Click here to view code image
R5#show ip igmp groups 239.1.1.1
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 Ethernet0/0 01:14:42 00:02:16 10.1.6.2
R5#
Ensure that the router has the RP information aligned to the scope range of the multicast group
(using the show ip pim rp mapping command) and document the outgoing interface to reach the RP
(using the show ip rpf RP_address command):
Click here to view code image
R5# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16
RP 192.168.100.100 (?), v2v1
Info source: 192.168.100.100 (?), elected via Auto-RP
Uptime: 01:13:19, expires: 00:00:20
R5#show ip rpf 192.168.100.100
RPF information for ? (192.168.100.100)
RPF interface: Ethernet2/0
RPF neighbor: ? (10.1.5.1)
RPF route/mask: 192.168.100.100/32
RPF type: unicast (ospf 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
c. Verify the (*,G) state at the LHR and check the RP for the (*,G) entry and RPF.
The objective is to verify the registration of the receiver to the RP, consequently seeing the (*,G)
entry.
Next, confirm that R5 is connected to the receiver, using the show ip mroute command:
Click here to view code image
R5#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
 x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 1d22h/00:03:02, RP 192.168.100.100, flags: SJC
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 1d22h/00:03:02
The incoming interface is Ethernet2/0 for the shared tree (*,G) connected to the RP
(192.168.100.100), and the outgoing interface shows the receiver connection.
Verify the multicast state at the RP (R4):
Click here to view code image
R4#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 1d19h/00:02:43, RP 192.168.100.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet2/0, Forward/Sparse, 1d19h/00:02:43
The output for the RP shows the outgoing interface (Ethernet2/0) connected to the LHR; this
matches the steady state topology.
The next step is to confirm that the RP address (*,G) entry is installed on the LHR and to check
RPF.
The show ip rpf RP command points to the next hop in the (*,G) tree. Use this command in
conjunction with the show ip mroute command to verify the appropriate interface:
Click here to view code image
R5#show ip rpf 192.168.100.100
RPF information for ? (192.168.100.100)
RPF interface: Ethernet2/0
RPF neighbor: ? (10.1.5.1)
RPF route/mask: 192.168.100.100/32
RPF type: unicast (eigrp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
R5#
R5#show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:02:35/00:02:50, RP 192.168.100.100, flags: SJCF
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:02:35/00:02:50
(10.1.1.1, 239.1.1.1), 00:02:21/00:00:38, flags: T
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:02:21/00:03:28
The highlighted text indicates symmetry between the mroute state and RPF state.
Step 2. Make sure you have an active source before trying to debug:
a. Verify multicast traffic on the incoming interface (Ethernet0/0) of the first-hop router (FHR) R2:
Click here to view code image
R2#show interface Ethernet0/0 | include multicast
Received 1182 broadcasts (33 IP multicasts)
R2#show interface Ethernet0/0 | include multicast
Received 1182 broadcasts (35 IP multicasts)
R2#show interface Ethernet0/0 | include multicast
Received 1183 broadcasts (36 IP multicasts)
R2#show interface Ethernet0/0 | include multicast
Received 1184 broadcasts (37 IP multicasts)
The output shows the increase in the IP multicast packets received on the interface that connect to
the source.
b. Confirm that the FHR has registered the group with the RP:
Make sure the FHR is aware of the RP using the show ip pim rp mapping command:
Click here to view code image
R2#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16
RP 192.168.100.100 (?), v2v1
 Info source: 192.168.100.100 (?), elected via Auto-RP
Uptime: 01:25:28, expires: 00:00:24
R2#
Verify that the FHR is sending packets to the RP (unicast register packets):
Click here to view code image
R2# show interface tunnel 0 | include output
Last input never, output 00:00:19, output hang never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute output rate 0 bits/sec, 0 packets/sec
15 packets output, 1920 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
R2#clear ip mroute 239.1.1.1
R2# show interface tunnel 0 | include output
Last input never, output 00:00:04, output hang never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute output rate 0 bits/sec, 0 packets/sec
16 packets output, 2048 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
R2#
You may be wondering about where the tunnel interface came from. The tunnel 0 interface is
automatically created by enabling multicast on the downstream router. This tunnel is used to
encapsulate the unicast register packets to the RP.
c. Determine that the RP is receiving the registry messages.
Use the debug ip pim <mcast_group_address > command.
R3 shows the registry message received and register stop sent. The register stop will be sent only
if the multicast state has active receivers in the shared tree:
Click here to view code image
Mar 15 20:11:13.030: PIM(0): Received v2 Register on Ethernet2/0 from
10.1.2.1
*Mar 15 20:11:13.030: for 10.1.1.1, group 239.1.1.1
*Mar 15 20:11:13.030: PIM(0): Send v2 Register-Stop to 10.1.2.1 for
10.1.1.1, group 239.1.1.1
d. Confirm that the multicast state is built on the FHR (R2):
Click here to view code image
R2#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
 T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:00:36/stopped, RP 192.168.100.100, flags: SPF
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.2
Outgoing interface list: Null
(10.1.1.1, 239.1.1.1), 00:00:36/00:02:23, flags: FT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.1
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:00:17/00:03:12
The multicast state indicates the (S,G) is built with FT flags. The incoming interface is connected
to the source and the outgoing interface shows that the packet-forwarding takes the best path between
the source and receiver based on the unicast routing protocol.
The results shown in this section are steady state. It is important to understand the commands and
steady state condition. During troubleshooting, use the steady state information with the output
collected during troubleshooting to compare and assess the problems.
State Verification
There are two primary components to state verification; these include RP control-plane check and
hop-by-hop state validation.
RP Control-Plane Check
Figure 7-2 is used to provide an example of state behavior in which the SPT uses the following
path, Source -> R2 -> R3 -> R4 -> R5 -> Receiver. In this example, the interface between R2 and R5
is shut down, forcing R2 to choose the path to R3 and R4. This is done to verify the switchover of the
multicast flow from (*,G) to (S,G) following the best path selected by the unicast routing protocol.
 Figure 7-2 Multicast State Flow via the RP
This would essentially be step 3 in the baselining process, as shown here:
Step 3. Verify RP and SPT state entries across the path:
a. Check the MSDP summary to verify peering is operational.
b. Verify the group state at each active RP.
c. Verify SPT changes.
This configuration, covered in Chapter 4 , uses the hybrid RP design and Auto-RP for downstream
propagation of the RP.
Step 3a. Check the MSDP summary to verify peering is operational:
Click here to view code image
R3# show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
Downtime Count Count
*192.168.4.4 ? Up 00:02:16 1 0 ?
The show ip msdp summary command verifies that the MSDP relationship is operational between
the RPs. This relationship is not impacted by the multicast data flow state in the mroute table.
Step 3b. Verify the group state at each active RP (R3 and R4):
Click here to view code image
R3#show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:08:39/stopped, RP 192.168.100.100, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.1.1.1, 239.1.1.1), 00:00:16/00:02:43, flags: TA
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.1
Outgoing interface list:
Ethernet3/0, Forward/Sparse, 00:00:16/00:03:13
R4# show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:08:45/00:03:02, RP 192.168.100.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
Ethernet2/0, Forward/Sparse, 00:01:08/00:02:38
(10.1.1.1, 239.1.1.1), 00:00:27/00:02:32, flags: MT
Incoming interface: Ethernet3/0, RPF nbr 10.1.4.1
Outgoing interface list:
Ethernet2/0, Forward/Sparse, 00:00:27/00:03:02
The RP (R4) is closest to the receiver and will consequently be the RP that receives the join
request from the LHR (R5). Comparing the output above, notice the outgoing interface list is NULL on
R3 and R4 is using Ethernet2/0. This shows that R4 is the active RP. The “T” flags on both R3 and R4
indicate the SPT has been established. The flags “A” and “M” on routers R3 and R4, respectively,
indicate that R3 is the candidate RP and that the entry was created by MSDP.
Step 3c. Verify SPT changes.
Review the multicast state at the RP after the connection between R2 and R5 is restored; refer to
Figure 7-3 .

Figure 7-3 Multicast Steady State Topology

With the R2 to R5 connection restored, the SPT flow no longer traverses the R2, R3, R4, R5 path
but rather the R2, R5 path. Notice the P flag set in (S,G) entry. This shows the multicast stream has
been pruned. The (*,G) state still will have receiver information via Ethernet2/0 as the outgoing
interface:
Click here to view code image
R4#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry,
E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP
Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
 G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner,
p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 1d21h/00:03:08, RP 192.168.100.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet2/0, Forward/Sparse, 1d21h/00:03:08
(10.1.1.1, 239.1.1.1), 00:07:57/00:02:19, flags: PMT
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.2
Outgoing interface list: Null
You should be very familiar with multicast flows traversing through the RP and those that do not.
You will undoubtedly encounter both situations as you implement and troubleshoot multicast
networks.
It would be terribly inefficient for multicast messages to always traverse the RP. We saw that
multicast traffic moved to the SPT in Step 3c. How does this happen? Let’s review the SPT process.
R5 is the LHR and also the location where there is a better (lower-cost) unicast route to the source.
Use the show ip mroute command to monitor the incoming interface for the (S,G) and (*,G) shift,
as demonstrated in Example 7-3 .
Example 7-3 show ip mroute Command Output
Click here to view code image
R5#show ip mroute 239.1.1.1
..
(*, 239.1.1.1), 00:02:31/00:02:55, RP 192.168.100.100, flags: SJC
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:02:31/00:02:55
(10.1.1.1, 239.1.1.1), 00:02:31/00:00:28, flags: T
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:02:31/00:03:14
In this example, R5 shows Ethernet1/0 will be selected as the RPF towards the source address
10.1.1.1. This is shown using the show ip rpf command, as demonstrated in Example 7-4 .
Example 7-4 show ip rpf Command Output
Click here to view code image
R5#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
RPF interface: Ethernet1/0
RPF neighbor: ? (10.1.3.1)
RPF route/mask: 10.1.1.0/24
RPF type: unicast (ospf 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
R5#
We can also see additional details using the debug ip pim command, as shown in the output in
Example 7-5 . Pay particular attention to the highlighted section.
Example 7-5 debug ip pim Output
Click here to view code image
! Start the debug and wait for the state to change
R5#
R5#debug ip pim 239.1.1.1
PIM debugging is on
R5#
*Mar 26 18:44:59.351: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.2.2 on Ethernet1/0 from
LOADING to FULL, Loading Done
R5#
*Mar 26 18:45:08.556: PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.1.6.2,
to us
*Mar 26 18:45:08.557: PIM(0): Join-list: (10.1.1.1/32, 239.1.1.1), S-bit set
*Mar 26 18:45:08.557: PIM(0): Update Ethernet0/0/10.1.6.2 to (10.1.1.1, 239.1.1.1),
Forward state, by PIM SG Join
R5#
*Mar 26 18:45:10.261: PIM(0): Insert (10.1.1.1,239.1.1.1) join in nbr 10.1.3.1's queue
*Mar 26 18:45:10.261: PIM(0): Insert (10.1.1.1,239.1.1.1) prune in nbr 10.1.5.1's
queue
*Mar 26 18:45:10.261: PIM(0): Building Join/Prune packet for nbr 10.1.5.1
*Mar 26 18:45:10.261: PIM(0): Adding v2 (10.1.1.1/32, 239.1.1.1), S-bit Prune
*Mar 26 18:45:10.261: PIM(0): Send v2 join/prune to 10.1.5.1 (Ethernet2/0)
*Mar 26 18:45:10.261: PIM(0): Building Join/Prune packet for nbr 10.1.3.1
*Mar 26 18:45:10.261: PIM(0): Adding v2 (10.1.1.1/32, 239.1.1.1), S-bit Join
*Mar 26 18:45:10.261: PIM(0): Send v2 join/prune to 10.1.3.1 (Ethernet1/0)
R5#
*Mar 26 18:45:10.324: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune mes-
sage for 239.1.1.1
*Mar 26 18:45:10.324: PIM(0): Insert (*,239.1.1.1) join in nbr 10.1.5.1's queue
*Mar 26 18:45:10.324: PIM(0): Insert (10.1.1.1,239.1.1.1) sgr prune in nbr
10.1.5.1's queue
*Mar 26 18:45:10.324: PIM(0): Building Join/Prune packet for nbr 10.1.5.1
*Mar 26 18:45:10.324: PIM(0): Adding v2 (192.168.100.100/32, 239.1.1.1), WC-bit,
RPT-bit, S-bit Join
*Mar 26 18:45:10.324: PIM(0): Adding v2 (10.1.1.1/32, 239.1.1.1), RPT-bit, S-bit
Prune
*Mar 26 18:45:10.324: PIM(0): Send v2 join/prune to 10.1.5.1 (Ethernet2/0)
R5#
*Mar 26 18:45:24.124: PIM(0): Insert (10.1.1.1,239.1.1.1) join in nbr 10.1.3.1's
queue
*Mar 26 18:45:24.125: PIM(0): Building Join/Prune packet for nbr 10.1.3.1
*Mar 26 18:45:24.125: PIM(0): Adding v2 (10.1.1.1/32, 239.1.1.1), S-bit Join
*Mar 26 18:45:24.125: PIM(0): Send v2 join/prune to 10.1.3.1 (Ethernet1/0)
*Mar 26 18:45:24.256: PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.1.6.2,
to us
*Mar 26 18:45:24.256: PIM(0): Join-list: (10.1.1.1/32, 239.1.1.1), S-bit set
*Mar 26 18:45:24.256: PIM(0): Update Ethernet0/0/10.1.6.2 to (10.1.1.1, 239.1.1.1),
Forward state, by PIM SG Join
R5#sh ip mroute 239.1.1.1
*Mar 26 18:45:41.349: PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.1.6.2,
to us
*Mar 26 18:45:41.349: PIM(0): Join-list: (*, 239.1.1.1), RPT-bit set, WC-bit set,
S-bit set
*Mar 26 18:45:41.349: PIM(0): Update Ethernet0/0/10.1.6.2 to (*, 239.1.1.1), Forward
state, by PIM *G Join
*Mar 26 18:45:41.349: PIM(0): Update Ethernet0/0/10.1.6.2 to (10.1.1.1, 239.1.1.1),
Forward state, by PIM *G Join
From the previous debug, please note the change from 10.1.5.1 to 10.1.3.1 (PIM join state for S,G)
and note also the “S-Bit Join” message that indicates the transition to the SPT. During the triggered
(*,G) state, the DR creates a join/prune message with the WC-bit and RPT-bit set to 1. The WC-bit
set to 1 indicates that any source may match this entry, and the flow will follow the shared tree. When
the RPT-bit is set to 1, it shows that the join is associated with the shared tree and the join/prune
message is sent along the shared tree towards the RP.
Hop-by-Hop State Validation
Up to this point in the troubleshooting process, we have covered the fundamentals—source and
receiver verification and RP control-plane confirmation. If we have not solved the multicast problem,
the troubleshooting methodology will be done on a hop-by-hop basis from the LHR to the FHR. For
this to be accomplished correctly, you must have a thorough understanding of the entire topology.
Note
When you are under pressure to solve a problem, this is not the time to begin documenting the
network. There should already be a comprehensive network diagram available.
The network diagram in Figure 7-4 aids in identifying the path between the source and the receiver.
This begins the next phase of the troubleshooting process—understanding the flow.
 Figure 7-4 Multicast (S,G) Path Flow
Figure 7-4 is a simple reference topology. Whether you are troubleshooting something very simple
or very complex, the process is still the same in assessing the health of the multicast network.
We begin by establishing the appropriate (S,G) path. Because this is a network we are familiar
with from previous examples, we know that the (S,G) path uses R2 and R5. We begin our
troubleshooting effort at the LHR and then work towards the FHR.
High-level steps:
Step 4. Verify the mroute state information for the following elements:
a. Validated that the IIF is correct?
b. Verify that the OIF is correct?
c. Are the “flags” for (*, G) and (S, G) entries correct?
d. Verify that the RP information is correct?
If there are anomalies from the previous steps, verify that each entry contains RFP information with
the show ip rpf ip-address command and move up the shortest-path toward the source. The questions
to ask yourself based on the output are:
Does this align with the information in the mroute entry?
Is this what you would expect when looking at the unicast routing table?
Now let’s review each element shown in Step 4. R5 is the LHR where we begin the process. Using
the show ip mroute command, we can verify that the state information for 239.1.1.1 is maintained
correctly by examining the elements, as shown in Example 7-6 :
Example 7-6 Multicast State at R5(LHR)
Click here to view code image
R5#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
 Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 2d01h/00:03:22, RP 192.168.100.100, flags: SJC
Incoming interface: Ethernet2/0, RPF nbr 10.1.5.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 2d01h/00:03:22
(10.1.1.1, 239.1.1.1), 00:04:53/00:02:31, flags: T
Incoming interface: Ethernet1/0, RPF nbr 10.1.3.1
Outgoing interface list:
Ethernet0/0, Forward/Sparse, 00:04:53/00:03:22
From the output in Example 7-6 , we can answer the following questions and verify the appropriate
operation:
Step 4a. Validated that the IIF is correct?
(*,G) Ethernet2/0 points to the RP.
(S,G) Ethernet 1/0 based on RPF to the source.
Step 4b. Verify that the OIF is correct?
(*,G) Ethernet 0/0 points towards the receiver.
(S,G) Ethernet 0/0 points towards the receiver.
Step 4c. Are the “flags” for (*, G) and (S, G) entries correct?
(*,G) state: SJC.
(S,G) state: T.
Step 4d. Verify that the RP information is correct?
192.168.100.100 (The Anycast Auto-RP learned from R3 and R4.)
Taking a systematic approach to determining the root cause of the problem, we continue examining
each device in the path toward the FHR. For brevity, here we jump to the FHR and use the show ip
mroute command to inspect the multicast state, as demonstrated in Example 7-7 .
Example 7-7 Multicast State at R2 (FHR)
Click here to view code image
R2#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
 X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:08:48/stopped, RP 192.168.100.100, flags: SPF
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.2
Outgoing interface list: Null
(10.1.1.1, 239.1.1.1), 00:08:48/00:02:41, flags: FT
Incoming interface: Ethernet0/0, RPF nbr 10.1.1.1
Outgoing interface list:
Ethernet1/0, Forward/Sparse, 00:08:48/00:02:36
The “T” flag indicates that multicast traffic is flowing using the (S, G) state entry.
We can use the output of Example 7-7 to validate the correct operation and answer the following
troubleshooting questions.
Step 4a. Validated that the IIF is correct?
(*,G) Ethernet2/0 points to the RP.
(S,G) Ethernet0/0 based on RPF to the source.
Step 4b. Verify that the OIF is correct?
(*,G) NULL; no receiver state on shared tree.
(S,G) Ethernet1/0 points towards the receiver.
Step 4c. Are the “flags” for (*, G) and (S, G) entries correct?
(*,G) state: SPF.
(S,G) state: FT.
Step 4d. Verify that the RP information is correct?
192.168.100.100.
The (*,G) is in a pruned state after registration. This is based on the switch from the shared to the
source tree following the unicast best path between the source and receiver. The (S,G) shows the
“FT” flags. The packet is flowing via the shortest path tree, and it is the first-hop router for registry.
The fundamental troubleshooting considerations previously covered are applicable for IPv4 and
IPv6 multicast environments. In the following section, we review some of the common tools used in
IOS for multicast troubleshooting.
Overview of Common Tools for Multicast Troubleshooting
 In many situations during troubleshooting, we may need to generate synthetic traffic using a
traditional tool such as ping , or we may be required to determine the source of intermittent problems
or network performance challenges that would require the use of a more sophisticated tool such as an
IP service level agreement (SLA). We may also be required to move beyond the traditional show
commands to gain additional insight into the operation or the lack of correct operation in the network.
Ping Test
The multicast ping test is a traditional troubleshooting tool used by network engineers to verify the
control and data planes. The test does not remove application centric problems, but it can be used to
verify the network infrastructure.
As shown in Figure 7-5 , we begin by assigning a router interface to a join-group.

Figure 7-5 Multicast Ping Test Procedure

Step 1. Add an IGMP Join group to simulate the receiver at the LHR:
Click here to view code image
R3#show run interface Ethernet0/0
Building configuration...
Current configuration : 114 bytes
!
interface Ethernet0/0
ip address 10.1.6.2 255.255.255.0
ip pim sparse-mode
ip igmp join-group 239.1.1.1
end
Step 2. Use multicast ping to send packets from the FHR:
Click here to view code image
R1#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
*Mar 23 21:27:15.209: ICMP: echo reply rcvd, src 10.1.6.2, dst
10.1.1.1, topology BASE, dscp 0 topoid 0
Reply to request 0 from 10.1.6.2, 34 ms
R1#
You can now verify the multicast state in the mroute table. This is a very simple method to
troubleshoot a multicast network. It also serves as a method to verify multicast functionality prior to
implementing a multicast service.
Note
Use caution when using the ip igmp join-group command because it causes the device to process
switch all packets to the configured multicast address. This can lead to high CPU utilization. This
command should be removed immediately after troubleshooting, and it should not be used to test live
multicast application traffic.
SLA Test
The IP service level agreement (SLA) feature provides the ability to analyze applications and
services through the generation of synthetic traffic. With the IP SLA feature, you can measure one-way
latency, jitter, and packet loss.
This is accomplished using two elements, a sender that generates UDP packets at a given interval
to a particular destination or destinations, and a receiver, or multiple receivers, that collect and
analyze the synthetic traffic and send a response back to the sender.
At the time of this writing, the following code releases support SLA multicast:
15.2(4)M
15.3(1)S
Cisco IOS XE Release 3.8S
15.1(2)SG
Cisco IOS XE Release 3.4SG
Example 7-8 and Example 7-9 show the sender and receiver configurations.
Example 7-8 Sender Configuration
Click here to view code image
ip sla endpoint-list type ip RCVRS
ip-address 10.1.6.2 port 5000
ip sla 10
udp-jitter 239.1.1.101 5000 endpoint-list RCVRS source-ip 10.1.1.1 source-port 5000
num-packets 50 interval 25
request-data-size 128
tos 160
verify-data
tree-init 1
control timeout 4
control retry 2
dscp 10
threshold 1000
timeout 10000
frequency 10
history hours-of-statistics-kept 4
 history distributions-of-statistics-kept 5
history statistics-distribution-interval 10
history enhanced interval 60 buckets 100
ip sla schedule 10 life forever start-time now
Example 7-9 Receiver Configuration
Click here to view code image
ip sla responder
ip sla responder udp-echo ipaddress 10.1.1.1 port 5000
Use the show commands in Example 7-10 to verify the condition of the multicast probes.
Example 7-10 Verifying Multicast Probe Condition
Click here to view code image
R1#show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 10
Owner:
Tag:
Operation timeout (milliseconds): 10000
Type of operation to perform: mcast
Endpoint list: RCVRS
Target address/Source address: 239.1.1.100/10.1.1.1
Target port/Source port: 5000/5001
Type Of Service parameter: 0xA0
Request size (ARR data portion): 128
Packet Interval (milliseconds)/Number of packets: 25/50
Verify data: Yes
Vrf Name:
DSCP: 10
Number of packets to set multicast tree: 1
SSM: disabled
Control message timeout(seconds): 4
Control message retry count: 2
Schedule:
Operation frequency (seconds): 10 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 1000
Distribution Statistics:
Number of statistic hours kept: 4
 Number of statistic distribution buckets kept: 5
Statistic distribution interval (milliseconds): 10
Enhanced History:
Aggregation Interval:60 Buckets:100
Entry number: 2132304746
Type of operation: mcast
Multicast operation id: 10
Target address/Source address: 10.1.6.2/10.1.1.1
Target port/Source port: 5000/5001
Multicast address: 239.1.1.100
R6#show ip sla endpoint-list type ip
Endpoint-list Name: RCVRS
Description:
List of IPV4 Endpoints:
ip-address 10.1.6.2 port 5000
Common Multicast Debug Commands
It is advisable to enable the debug commands during a maintenance window with Cisco TAC
assistance. The following debug commands help provide additional insight during troubleshooting.
debug ip mpacket Command
The debug ip mpacket command provides packet details for the multicast packets traversing the
L3 device, as shown in Example 7-11 .
Example 7-11 Verifying Multicast Probe Condition
Click here to view code image
*Sep 04 14:48:01.651: IP: s=10.1.1.1 (Ethernet1/0) d=239.1.1.1 (Serial0/0) ld
*Sep 04 14:48:02.651: IP: s=10.1.1.1 (Ethernet1/0) d=239.1.1.1 (Serial0/0) ld
*Sep 04 14:48:03.651: IP: s=10.1.1.1 (Ethernet1/0) d=239.1.1.1 (Serial0/0) ld
debug ip pim Command
The debug ip pim command shows the all PIM packets flowing through the device and is useful for
understanding PIM state.
The debug is taken from a RP configured in hybrid ASM mode with Auto-RP. The messages show a
group join using 239.1.1.1 and group 239.1.1.2 that has a receiver with no active sources. The output
also indicates the RP election of 192.168.100.100 as a candidate. Example 7-12 shows the output of
debug ip pim .
Example 7-12 depug ip pim Output
Click here to view code image
R3#show logging
*Mar 17 21:41:37.637: PIM(0): check pim_rp_announce 1
*Mar 17 21:41:37.637: PIM(0): send rp announce
*Mar 17 21:41:44.657: PIM(0): Received v2 Join/Prune on Ethernet2/0 from 10.1.2.1,
to us
*Mar 17 21:41:44.658: PIM(0): Join-list: (*, 239.1.1.2), RPT-bit set, WC-bit set,
S-bit set
*Mar 17 21:41:44.658: PIM(0): Check RP 192.168.100.100 into the (*, 239.1.1.2) entry
*Mar 17 21:41:44.658: PIM(0): Adding register decap tunnel (Tunnel1) as accepting
interface of (*, 239.1.1.2).
*Mar 17 21:41:44.658: PIM(0): Add Ethernet2/0/10.1.2.1 to (*, 239.1.1.2), Forward
state, by PIM *G Join
*Mar 17 21:41:45.658: PIM(0): Received v2 Register on Ethernet2/0 from 10.1.2.1
*Mar 17 21:41:45.658: for 10.1.1.1, group 239.1.1.1
*Mar 17 21:41:45.658: PIM(0): Check RP 192.168.100.100 into the (*, 239.1.1.1) entry
*Mar 17 21:41:45.658: PIM(0): Adding register decap tunnel (Tunnel1) as accepting
interface of (*, 239.1.1.1).
*Mar 17 21:41:45.658: PIM(0): Adding register decap tunnel (Tunnel1) as accepting
interface of (10.1.1.1, 239.1.1.1).
*Mar 17 21:41:45.659: PIM(0): Send v2 Register-Stop to 10.1.2.1 for 10.1.1.1, group
239.1.1.1
*Mar 17 21:41:47.633: PIM(0): check pim_rp_announce 1
*Mar 17 21:41:47.633: PIM(0): send rp announce
*Mar 17 21:41:47.634: PIM(0): Received v2 Assert on Ethernet3/0 from 10.1.4.2
*Mar 17 21:41:47.634: PIM(0): Assert metric to source 192.168.100.100 is [0/0]
*Mar 17 21:41:47.634: PIM(0): We lose, our metric [0/0]
*Mar 17 21:41:47.634: PIM(0): Insert (192.168.100.100,224.0.1.39) prune in nbr
10.1.4.2's queue
*Mar 17 21:41:47.634: PIM(0): Send (192.168.100.100, 224.0.1.39) PIM-DM prune to oif
Ethernet3/0 in Prune state
*Mar 17 21:41:47.634: PIM(0): (192.168.100.100/32, 224.0.1.39) oif Ethernet3/0 in Prune state
*Mar 17 21:41:47.634: PIM(0): Building Join/Prune packet for nbr 10.1.4.2
*Mar 17 21:41:47.634: PIM(0): Adding v2 (192.168.100.100/32, 224.0.1.39) Prune
*Mar 17 21:41:47.634: PIM(0): Send v2 join/prune to 10.1.4.2 (Ethernet3/0)
*Mar 17 21:41:51.022: PIM(0): Received v2 Assert on Ethernet3/0 from 10.1.4.2
*Mar 17 21:41:51.022: PIM(0): Assert metric to source 192.168.100.100 is [0/0]
debug ip igmp Command
The output of debug ip igmp command at LHR (R5) provides details regarding the IGMP packets.
As shown in Example 7-13 , the router receives a join from 239.1.1.1 and then adds a multicast (*,G)
entry to add the receiver state in the multicast entry.
Example 7-13 depug ip igmpt Output
Click here to view code image
*Mar 17 21:50:45.703: IGMP(0): Received v2 Report on Ethernet0/0 from 10.1.6.2 for
239.1.1.1
*Mar 17 21:50:45.703: IGMP(0): Received Group record for group 239.1.1.1, mode 2
from 10.1.6.2 for 0 sources
*Mar 17 21:50:45.703: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Mar 17 21:50:45.703: IGMP(0): MRT Add/Update Ethernet0/0 for (*,239.1.1.1) by 0
*Mar 17 21:50:45.704: IGMP(0): Received v2 Report on Ethernet0/0 from 10.1.6.2 for
239.1.1.1
*Mar 17 21:50:45.704: IGMP(0): Received Group record for group 239.1.1.1, mode 2
from 10.1.6.2 for 0 sources
*Mar 17 21:50:45.704: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Mar 17 21:50:45.704: IGMP(0): MRT Add/Update Ethernet0/0 for (*,239.1.1.1) by 0
Multicast Troubleshooting
Figure 7-6 shows the three basic blocks that you need to understand to support our multicast
troubleshooting efforts.

Figure 7-6 Multicast Troubleshooting Blocks

Before you begin troubleshooting, you need to understand each domain for your multicast
environment and then tie it to the appropriate troubleshooting steps to the respective domain.
I. Application Scope Review (the scope of the application that is not working):
Are the receivers local to the source?
Are the receivers across the WAN?
Verify the bandwidth of the multicast group for the application and validate latency-specific
parameters.
Verify the addressing scheme used in the enterprise.
II. Unicast Domain Scope Review:
What is the Unicast routing protocol design?
What is the path between the source and destination for the multicast flow?
What are the WAN technologies such as IPSEC, MPLS-VPN? Is this offering from a service
provider or self-managed, and so on?
What is the QoS design and does it align to the class that is configured for that multicast service?
III. Multicast Domain:
What is the PIM configuration? (ASM, SSM, or BiDir)
Verify the number of multicast states in the network.
Verify the best practices have been followed for PIM control-plane configuration, explained in
Chapter 5 .
Verify the configuration of the downstream routers.
These are some high-level steps used to understand the multicast environment. Earlier in the
chapter we reviewed a through step-by-step approach to identify a multicast issue. Let us review a
case study to understand the troubleshooting process.
Multicast Troubleshooting Case Study
Problem: Multicast is not working for few multicast groups in the network.
Troubleshooting:
I. Application Scope Review: Items to consider while you review the application:
The scope of the application.
1.1 Are any multicast applications in the network currently functioning?
Answer: Multicast groups across in other regions are working.
1.2 Are all the groups that are not working a part of the same multicast RP group?
Answer: Yes.
1.3 Are there any working groups with the scope range?
Answer: No.
1.4 Was it working before?
Answer: Yes.
1.5 What changes were made in the environment?
Answer: I don’t know.
The bandwidth of the stream for the single multicast group.
Comment: At this point, when you have a nonworking group, the bandwidth does not play a
significant role.
What are the latency specific parameters for multicast stream distribution?
Comment: With a nonfunctional group, latency information does not play an important part.
What type of multicast address scheme is used by the source?
Answer: Scoped using the range of 239.x.x.x space.
II. Unicast Domain Scope Review: Things to consider in this domain:
Unicast routing protocol architecture.
What is the underlying unicast protocol?
Answer: OSPF and BGP.
Is there any unicast routing reachability issues?
Answer: No.
What is the path between the source and destination and identify the source and destination
(single out a multicast group)?
Answer: Draw the path between the, source, RP, and receiver. It is beneficial to understand this
path while troubleshooting the multicast control plane.
Is there a WAN technology overlay, such as IPsec, MPLS-VPN?
Answer: Dedicated point-to-point connections with no IPsec or MPLS-VPNs.
Note
 IPsec does not natively support multicast transport. An overlay technology should be considered,
such as GRE, DMVPN or GETVPN, to transport multicast with IPSEC encryption.
Does the QoS architecture and class align to the multicast transport?
Comment: When there is no latency or sporadic user experience issue, then a review of QoS really
is not generally warranted.
III. PIM Domain: Things to consider in this domain:
What is the PIM configuration? (ASM, SSM, or BiDir)
Answer: ASM.
What is the multicast state in the network?
Answer: Not all the best practices are deployed; only ip pim register limit, boundary, and scoping
of the hybrid RP with Auto-RP has been deployed.
Are the best practices for PIM control plane deployed?
Answer: Only ip pim register-limit is configured.
Identify the RP location in the network for the application group (ASM).
Answer: The RP is in the data path, and the RP also functions as the campus core.
What is the configuration of the downstream router?
Answer: Only ip pim register-limit has been deployed.
Figure 7-7 will be used to explain the troubleshooting methodology.

Figure 7-7 Case Study: Multicast Troubleshooting Topology

Baseline Check: Source and Receiver Verification
Before you start the multicast baseline check, verify that the source and receiver have ping
reachability. Example 7-14 shows a unicast ping test from the receiver to the source IP (10.1.1.1).
Example 7-14 Verification of the Source Reachability from the Receiver
Click here to view code image
Receiver#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Step 1: Receiver Check
Table 7-1 Outlines the receiver verification steps.
Table 7-1 Receiver Verification Steps
Step 2: Source Check
Table 7-2 outlines the source verification steps before starting the multicast baseline check.
Table 7-2 Source Verification Steps
Make sure you have an active source before trying to troubleshoot.
 The Outgoing interface list points to NULL in Step 2c. At steady state, the outgoing interface should
point towards the RP in initial state. This is a problem in the state build that needs to be reviewed
further. Rather than reviewing Step 2d (debug message to verify state build-up at FHR), let’s move to
next step, state verification.
Step 3: State Verification
Table 7-3 outlines the baseline RP and control-plane verification steps.
Table 7-3 RP and Control-Plane Check
 As you observed earlier in Step 3, the RP control-plane check had inconsistencies. There is no
point in proceeding with Step 4, hop-by-hop state validation, until the inconsistencies are resolved.
This means it could be a control-plane problem. To further eliminate suspicion of application-based
issues, perform a multicast ping from FHR to LHR in the topology, as outlined in Figure 7-8 . The
multicast ping will simulate the application, becoming the new multicast source. This illuminates how
the state is built from Steps 1, 2, and 3 with a network source.

Figure 7-8 Multicast Ping Test Procedure

To create a receiver, configure an IGMP join group at R5(LHR) closest to the receiver. Use the ip
igmp join-group command. Use a multicast group that is not used in any production traffic and falls in
the multicast RP scope range. Example 7-15 shows the configuration.
Example 7-15 Create IGMP Join Group
Click here to view code image
R5#show run interface loopback 0
Building configuration...
Current configuration : 118 bytes
!
interface Loopback0
ip address 192.168.5.5 255.255.255.255
ip pim sparse-mode
ip igmp join-group 239.1.1.10
end
R5#
Verify connectivity to the unicast and multicast control plane from R2 (closest to the receiver), as
demonstrated in Example 7-16 .
Example 7-16 Multicast and Unicast Connectivity Check
Click here to view code image
R2#ping 192.168.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R2#ping 239.1.1.10
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.100, timeout is 2 seconds:
.
R2#
The unicast ping test is successful at R2, but the multicast ping is not successful. This test is done
merely to remove application anomalies. The output clearly shows that this test is not successful and
confirms that this is a control-plane issue in the network.
Summary of the failed tests:
Steps 2b and 2c: FHR registration to the RP failed, and the RP state flags for multicast were
incorrect.
Step 3c: Failure of the RP state exchanges; the state at R3 did not provide correct results because
the (S,G) group was in a pruned state.
Figure 7-9 shows the fundamental overview of the three troubleshooting steps:

Figure 7-9 Troubleshooting Case Study: Focus Area

The multicast control plane is broken at Step 1 or Step 3. The areas of concern include R2, R3, and
R4. It is recommended to work with Cisco TAC during troubleshooting because we will be using
debug commands to understand the PIM control-plane flow. It is also recommended to plan a change
control window prior to executing debug commands, because it might impact other network functions.
To verify the registry process, use the debug ip pim 239.1.1.1 command at R3, the output for which
is shown in Example 7-17 .
Example 7-17 Control-plane Debug Capture at R3
Click here to view code image
*Mar 21 20:48:06.866: PIM(0): Received v2 Register on Ethernet2/0 from 10.1.2.1
*Mar 21 20:48:06.866: for 10.1.1.1, group 239.1.1.1
*Mar 21 20:48:06.866: PIM(0): Check RP 192.168.100.100 into the (*, 239.1.1.1) entry
*Mar 21 20:48:06.866: PIM(0): Adding register decap tunnel (Tunnel1) as accepting
interface of (*, 239.1.1.1).
*Mar 21 20:48:06.866: PIM(0): Adding register decap tunnel (Tunnel1) as accepting
interface of (10.1.1.1, 239.1.1.1).
*Mar 21 20:48:06.866: PIM(0): Send v2 Register-Stop to 10.1.2.1 for 10.1.1.1, group
239.1.1.1
 PIM register packets are seen being sent and received. The question arises, why does the state at
R3 not show the receiver and instead shows the pruned state for the (S,G) entry? We need to do some
further investigation to determine the root cause; this moves our attention to Step 3.
We begin troubleshooting this by using the show ip mroute command on R3, as demonstrated in
Example 7-18 .
Example 7-18 show ip mroute Command Output
Click here to view code image
R3#show ip mroute 239.1.1.1
…
(*, 239.1.1.1), 00:04:21/stopped, RP 192.168.100.100, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.1.1.1, 239.1.1.1), 00:04:21/00:02:38, flags: PA
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.1
Outgoing interface list: Null→ Problem Area
This state flag relationship for the (S,G) entry does not look correct; the message is in the pruned
state; and the outgoing interface is set to NULL. The (*,G) also does not show any receiver
information.
The peer MSDP relationship between R3 and R4 shows the information of the source learned at
R4. This can be seen using the show ip msdp sa-cache command, as demonstrated in Example 7-19 .
Example 7-19 show ip msdp sa-cache Command Output
Click here to view code image
R4#show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(10.1.1.1, 239.1.1.1), RP 192.168.100.100, AS ?,00:08:46/00:05:22, Peer 192.168.3.3
R4#
R4 has the receiver information in its multicast state table, shown using the ip mroute command, as
demonstrated in Example 7-20 .
Example 7-20 Multicast State Table at R4
Click here to view code image
(*, 239.1.1.1), 5d22h/stopped, RP 192.168.100.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet2/0, Forward/Sparse, 5d22h/00:03:04
(10.1.1.1, 239.1.1.1), 00:00:18/00:02:41, flags: M
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet2/0, Forward/Sparse, 00:00:18/00:02:41
The control plane from the RPs (R3 and R4) looks fine; however, the state entry at R3 does not
show the multicast stream flowing. It cannot be an application issue because the multicast ping test
did not succeed. The multicast state does not show R3 forwarding the (S,G) state to R4, which has the
receiver entry in the (*,G) state table, and consequently the group is in a pruned state for the (S,G) at
R3 (refer to the “problem area” identified in the show ip mroute at R3). The R3 and R4 multicast
state table exchange between the RP is based on MSDP feature.
Verify the data plane interface with the multicast control plane for congruency.
At R3, check the Layer 3 routing relationship with the PIM relationship. This is accomplished
using the show ip ospf neighbor command to determine the state of the routing adjacency and the
show ip pim neighbor command to show the PIM neighbor relationship. Example 7-21 shows output
from the show ip ospf neighbor command.
Example 7-21 show ip ospf neighbor and show ip pim neighbor Command Output for R3
Click here to view code image
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.4.4 1 FULL/BDR 00:00:38 10.1.4.2 Ethernet3/0
192.168.2.2 1 FULL/DR 00:00:37 10.1.2.1 Ethernet2/0
R3# show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.2.1 Ethernet2/0 6d02h/00:01:34 v2 1 / S P G
R3#
Notice that Ethernet3/0 does not have a PIM relationship. This interface connects R3 to R4 and
could be the reason why the receiver PIM join did not make it to R3 from R4. To verify the
inconsistency, execute the same command at R4 and check the Layer 3 routing relationship with the
PIM relationship, as demonstrated in Example 7-22 .
Example 7-22 show ip ospf neighbor and show ip pim neighbor Command Output for R4
Click here to view code image
R4#show ip ospf neigbhor
Neighbor ID Pri State Dead Time Address Interface
192.168.3.3 1 FULL/DR 00:00:32 10.1.4.1 Ethernet3/0
192.168.5.5 1 FULL/DR 00:00:37 10.1.5.2 Ethernet2/0
R4#show ip pim neigbhor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.5.2 Ethernet2/0 6d02h/00:01:24 v2 1 / DR S P G
R4#
 The previous command verifies the failure of the PIM relationship between R3 and R4.
Check the configuration on R4, Ethernet3/0 and verify the existence of PIM routing using the
command show ip pim interface , as demonstrated in Example 7-23 .
Example 7-23 show ip pim interface Command Output for R4
Click here to view code image
R4#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
192.168.4.4 Loopback0 v2/S 0 30 1 192.168.4.4
192.168.100.100 Loopback100 v2/S 0 30 1 192.168.100.100
10.1.5.1 Ethernet2/0 v2/S 1 30 1 10.1.5.2
10.1.4.2 Ethernet3/0 v2/S 1 30 1 10.1.4.2
R4#
From the output we see that PIM sparse-mode is enabled on the interface.
Now we check the configuration on R3 Ethernet3/0 and verify the existence of PIM routing using
the show ip pim interface command on R3, as demonstrated in Example 7-24 .
Example 7-24 show ip pim interface Command Output for R3
Click here to view code image
R3#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.1.2.2 Ethernet2/0 v2/S 1 30 1 10.1.2.2
192.168.3.3 Loopback0 v2/S 0 30 1 192.168.3.3
192.168.100.100 Loopback100 v2/S 0 30 1 192.168.100.100
R3#
We can see from the output of this command that PIM has not been enabled on the Ethernet3/0
interface. This clearly indicates the problem.
To rectify the problem, we enable PIM sparse-mode on interface Ethernet 3/0 at R3 using the
commands shown in Example 7-25 .
Example 7-25 Enabling PIM Sparse-Mode on R3’s Ethernet 3/0 Interface
Click here to view code image
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface ethernet 3/0
R3(config-if)#ip pim sparse-mode
Now we need to verify that the configuration change resolved the problem using the show ip pim
neighbor command, as demonstrated in Example 7-26 .
Example 7-26 PIM Neighbor Overview
Click here to view code image
 R3#show ip pim neigbhor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.1.2.1 Ethernet2/0 6d03h/00:01:34 v2 1 / S P G
10.1.4.2 Ethernet3/0 00:00:55/00:01:18 v2 1 / DR S P G
R3#
R3#sh ip ospf nei
Neighbor ID Pri State Dead Time Address Interface
192.168.4.4 1 FULL/BDR 00:00:35 10.1.4.2 Ethernet3/0
192.168.2.2 1 FULL/DR 00:00:33 10.1.2.1 Ethernet2/0
This output shows that the neighbor adjacency is established.
Now we can test to verify if the source and receiver for 239.1.1.1 are able to communicate. To
verify the source is sending multicast traffic, we execute show ip mroute to check the multicast state
flags on R3, as demonstrated in Example 7-27 .
Example 7-27 Multicast State Table at R3
Click here to view code image
R3#show ip mroute 239.1.1.1
IP Multicast Routing Table
..
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:04:59/stopped, RP 192.168.100.100, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.1.1.1, 239.1.1.1), 00:04:59/00:02:17, flags: TA
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.1
Outgoing interface list:
Ethernet3/0, Forward/Sparse, 00:03:49/00:03:25
The flag “T” indicates that multicast flow is via R3 router. Now verify with multicast ping that it is
working properly, as demonstrated in Example 7-28 .
Example 7-28 Verifying the Multicast Ping
Click here to view code image
R2# ping 239.1.1.10 source l0 repeat 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 239.1.1.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.2
Reply to request 0 from 192.168.5.5, 19 ms
Reply to request 0 from 192.168.5.5, 19 ms
Reply to request 1 from 192.168.5.5, 1 ms
Reply to request 1 from 192.168.5.5, 1 ms
Reply to request 2 from 192.168.5.5, 1 ms
Reply to request 2 from 192.168.5.5, 1 ms
The test shows the ping is successful. The multicast of state of the group 239.1.1.1 on R3 shows the
appropriate information, as shown in Example 7-29 .
Example 7-29 Multicast State Table at R3
Click here to view code image
R3#sh ip mroute 239.1.1.10
IP Multicast Routing Table
..
(*, 239.1.1.10), 00:00:24/stopped, RP 192.168.100.100, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(192.168.2.2, 239.1.1.10), 00:00:24/00:02:35, flags: TA
Incoming interface: Ethernet2/0, RPF nbr 10.1.2.1
Outgoing interface list:
Ethernet3/0, Forward/Sparse, 00:00:24/00:03:05
The problem was caused due to PIM not being enabled on one of the links. Another command you
can verify to see the flow of multicast is the show ip mfib count , as shown in Example 7-30 .
Example 7-30 Multicast FIB Table to Check the Data Plane
Click here to view code image
R3#show ip mfib count | begin 239.1.1.1
Group: 239.1.1.1
RP-tree,
SW Forwarding: 0/0/0/0, Other: 0/0/0
Source: 10.1.1.1,
SW Forwarding: 9/0/100/0, Other: 0/0/0
Totals - Source count: 1, Packet count: 9
Group: 239.1.1.2
RP-tree,
SW Forwarding: 0/0/0/0, Other: 0/0/0
Group: 239.1.1.10
RP-tree,
SW Forwarding: 0/0/0/0, Other: 0/0/0
Source: 192.168.2.2,
SW Forwarding: 36/0/100/0, Other: 0/0/0
Totals - Source count: 1, Packet count: 36
This command changes based on the network platform you are using; however, it is an excellent
command to know if you want to verify data plane traffic.
Important Multicast show Commands
 This section explains several IOS, NX-OS, and IOS-XR commands useful in collecting pertinent
information on multicast. We recommend that you review Cisco.com command documentation to
understand other multicast commands that can be leveraged during troubleshooting.
show ip igmp group Command
This command is used to verify if the receiver has sent an IGMP request to join group 239.1.2.3.
The command syntax is the same for IOS, Nexus, and IOS-XR:
show ip igmp group group
Example 7-31 demonstrates sample output from this command.
Example 7-31 show ip igmp group Command Output
Click here to view code image
R1#sh ip igmp group 239.1.2.3
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
239.1.2.3 Ethernet1/0 00:01:07 never 172.16.8.6
show ip igmp interface/show igmp interface Commands
This command is used to verify the IGMP version, query interval/timeout, IGMP activity, query
router, and the multicast group that has been joined.
The command syntax for IOS and Nexus is:
Click here to view code image
show ip igmp interface interface-type
The command syntax for IOS-XR is:
Click here to view code image
show igmp interface interface-type
Example 7-32 demonstrates sample output from the show ip igmp interface command for IOS.
(The NX-OS output will be similar, but it is not shown here.)
Example 7-32 show ip igmp interface Command Output for IOS
Click here to view code image
R6#sh ip igmp interface Ethernet1/0
Ethernet1/0 is up, line protocol is up
Internet address is 172.16.8.6/24
IGMP is enabled on interface
Current IGMP version is 2
CGMP is disabled on interface
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 1 joins, 0 leaves
Multicast routing is enabled on interface
 Multicast TTL threshold is 0
Multicast designated router (DR) is 172.16.8.6 (this system)
IGMP querying router is 172.16.8.6 (this system)
Multicast groups joined (number of users):
239.1.2.3(1)
Example 7-33 demonstrates sample output from the show igmp interface command for IOS-XR.
Example 7-33 show igmp interface Command Output for IOS-XR
Click here to view code image
RP/0/0/CPU0:R1#sh igmp interface loopback 1
Wed Mar 23 07:52:13.139 UTC
Loopback1 is up, line protocol is up
Internet address is 10.100.1.1/32
IGMP is enabled on interface
Current IGMP version is 3
IGMP query interval is 60 seconds
IGMP querier timeout is 125 seconds
IGMP max query response time is 10 seconds
Last member query response interval is 1 seconds
IGMP activity: 4 joins, 0 leaves
IGMP querying router is 10.100.1.1 (this system)
Time elapsed since last query sent 00:00:48
Time elapsed since IGMP router enabled 00:02:07
Time elapsed since last report received 00:00:45
show ip mroute/show mrib route Command
This is a very useful command to understand the multicast flow. The information available from
this command helps understand the flags, RPF neighbor, RP information, OIL, and IIF. Note the
difference in the flag nomenclature between IOS and NX-OS. The information relayed is the same.
The command syntax for IOS and Nexus is:
show ip mroute
The command syntax for IOS-XR is:
show mrib route
Example 7-34 demonstrates sample output from the show ip mroute command for IOS.
Example 7-34 show ip mroute Command Output for IOS
Click here to view code image
R6> show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
M - MSDP created entry, X - Proxy Join Timer Running
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.1.1.1), 00:13:28/00:02:59, RP 10.1.5.1, flags: SCJ
Incoming interface: Ethernet0, RPF nbr 10.1.2.1,
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:13:28/00:02:32
Serial0, Forward/Sparse, 00:4:52/00:02:08
(171.68.37.121/32, 239.1.1.1), 00:01:43/00:02:59, flags: CJT
Incoming interface: Serial0, RPF nbr 192.10.2.1
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:01:43/00:02:11
Ethernet0, forward/Sparse, 00:01:43/00:02:11
Example 7-35 demonstrates sample output from the show ip mroute command for Nexus.
Example 7-35 show ip mroute Command Output for Nexus
Click here to view code image
nexusr1# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 232.0.0.0/8), uptime: 00:08:09, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
(*, 239.1.1.1/32), uptime: 00:07:22, pim ip
Incoming interface: loopback1, RPF nbr: 10.100.1.1
Outgoing interface list: (count: 1)
Ethernet2/2, uptime: 00:07:22, pim
(*, 239.1.1.100/32), uptime: 00:07:27, igmp ip pim
Incoming interface: loopback1, RPF nbr: 10.100.1.1
Outgoing interface list: (count: 1)
loopback0, uptime: 00:07:27, igmp
Example 7-36 demonstrates sample output from the show mrib route command for IOS-XR.
Example 7-36 show mrib route Command Output for IOS-XR
Click here to view code image
RP/0/0/CPU0:R1#show mrib route
Wed Mar 23 07:53:27.604 UTC
IP Multicast Routing Information Base
Entry flags: L - Domain-Local Source, E - External Source to the Domain,
C - Directly-Connected Check, S - Signal, IA - Inherit Accept,
IF - Inherit From, D - Drop, ME - MDT Encap, EID - Encap ID,
MD - MDT Decap, MT - MDT Threshold Crossed, MH - MDT interface handle
CD - Conditional Decap, MPLS - MPLS Decap, MF - MPLS Encap, EX - Extranet
MoFE - MoFRR Enabled, MoFS - MoFRR State, MoFP - MoFRR Primary
MoFB - MoFRR Backup, RPFID - RPF ID Set, X - VXLAN
Interface flags: F - Forward, A - Accept, IC - Internal Copy,
NS - Negate Signal, DP - Don't Preserve, SP - Signal Present,
 II - Internal Interest, ID - Internal Disinterest, LI - Local Interest,
LD - Local Disinterest, DI - Decapsulation Interface
EI - Encapsulation Interface, MI - MDT Interface, LVIF - MPLS Encap,
EX - Extranet, A2 - Secondary Accept, MT - MDT Threshold Crossed,
MA - Data MDT Assigned, LMI - mLDP MDT Interface, TMI - P2MP-TE MDT Interface
IRMI - IR MDT Interface
(*,239.0.0.0/8) RPF nbr: 10.100.1.1 Flags: L C RPF P
Up: 00:03:23
Outgoing Interface List
Decapstunnel0 Flags: NS DI, Up: 00:03:17
(*,239.1.1.100) RPF nbr: 10.100.1.1 Flags: C RPF
Up: 00:02:15
Incoming Interface List
Decapstunnel0 Flags: A NS, Up: 00:02:15
Outgoing Interface List
Loopback1 Flags: F IC NS II LI, Up: 00:02:15
RP/0/0/CPU0:R1#
show ip pim interface/show pim interface Commands
This command is useful for verifying the interfaces that are configured with PIM. The designated
router (DR) for segment is also shown using this command.
The command syntax for IOS and Nexus is:
show ip pim interface
The command syntax for IOS-XR is:
show pim interface
Example 7-37 demonstrates sample output from the show ip pim interface command for IOS. (The
NX-OS output is similar, but it is not shown here.)
Example 7-37 show ip pim interface Command Output for IOS
Click here to view code image
R6#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
172.16.10.6 Serial0/0 v2/Sparse 1 30 0.0.0.0
172.16.7.6 Ethernet0/1 v2/Sparse 1 30 172.16.7.6
172.16.8.6 Ethernet1/0 v2/Sparse 0 30 172.16.8.6
Example 7-38 demonstrates sample output from the show pim interface command for IOS-XR.
Example 7-38 show pim interface Command Output for IOS-XR
Click here to view code image
RP/0/0/CPU0:R1#show pim interface
Wed Mar 23 07:55:37.675 UTC
PIM interfaces in VRF default
Address Interface PIM Nbr Hello DR DR
 Count Intvl Prior
192.168.0.1 Loopback0 on 1 30 1 this system
10.100.1.1 Loopback1 on 1 30 1 this system
192.168.12.1 GigabitEthernet0/0/0/0 on 2 30 1 192.168.12.2
192.168.23.1 GigabitEthernet0/0/0/1 on 2 30 1 192.168.23.2
RP/0/0/CPU0:R1#
show ip pim neighbor/show pim neighbor Commands
After checking the PIM interface, this command helps verify the PIM adjacency between Layer 3
neighbors.
The command syntax for IOS and Nexus is:
show ip pim neighbor
The command syntax for IOS-XR is:
show pim neighbor
Example 7-39 demonstrates sample output from the show ip pim neighbor command for IOS. (The
NX-OS output is similar, but it is not shown here.)
Example 7-39 show ip pim neighbor Command Output for IOS
Click here to view code image
R6#show ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
172.16.10.3 Serial0/0 7w0d 00:01:26 v2
172.16.7.5 Ethernet0/1 7w0d 00:01:30 v2
Example 7-40 demonstrates sample output from the show pim neighbor command for IOS-XR.
Example 7-40 show pim neighbor Command Output for IOS-XR
Click here to view code image
RP/0/0/CPU0:R1#show pim neighbor
Wed Mar 23 07:56:42.811 UTC
PIM neighbors in VRF default
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
192.168.12.1* GigabitEthernet0/0/0/0 00:06:36 00:01:36 1 BPE
192.168.12.2 GigabitEthernet0/0/0/0 00:06:32 00:01:35 1 (DR) P
192.168.23.1* GigabitEthernet0/0/0/1 00:06:36 00:01:37 1 BPE
192.168.23.2 GigabitEthernet0/0/0/1 00:06:34 00:01:35 1 (DR) B P
192.168.0.1* Loopback0 00:06:37 00:01:20 1 (DR) B P E
10.100.1.1* Loopback1 00:06:37 00:01:19 1 (DR) B P E
RP/0/0/CPU0:R1#
show ip pim rp Command
 This command checks the RP information on a router. The Nexus command shows scope range and
RP propagation similar to the IOS show ip pim rp mapping command.
The command syntax for IOS and Nexus is:
show ip pim rp
Example 7-41 demonstrates sample output from the show ip pim rp command for IOS.
Example 7-41 show ip pim rp Command Output for IOS
Click here to view code image
R6#sh ip pim rp 239.1.2.3
Group: 239.1.2.3, RP: 111.1.1.1, v2, uptime 00:23:36, expires never
Example 7-42 demonstrates sample output from the show ip pim rp command for NX-OS.
Example 7-42 show ip pim rp Command Output for NX-OS
Click here to view code image
nexusr1# show ip pim rp
PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP disabled
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None
Anycast-RP 192.168.0.1 members:
10.100.1.1*
Anycast-RP 192.168.0.2 members:
10.100.1.1*
RP: 10.100.1.1*, (0), uptime: 00:04:42, expires: never,
priority: 0, RP-source: (local), group ranges:
239.0.0.0/8
nexusr1#
show ip pim rp mapping/show pim rp mapping Commands
This command checks the RP information on a router. The groups scoped for the RP and the RP
propagation method. NX-OS displays RP information details using the show ip pim rp command.
The command syntax for IOS is:
show ip pim rp mapping
The command syntax for IOS-XR is:
show pim rp mapping
Example 7-43 demonstrates sample output from the show ip pim rp mapping command for IOS.
Example 7-43 show ip pim rp mapping Command Output for IOS
Click here to view code image
R5# show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 239.1.0.0/16
RP 192.168.100.100 (?), v2v1
Info source: 192.168.100.100 (?), elected via Auto-RP
Uptime: 1w0d, expires: 00:00:24
Example 7-44 demonstrates sample output from the show pim rp mapping command for IOS-XR.
Example 7-44 show pim rp mapping Command Output for IOS-XR
Click here to view code image
RP/0/0/CPU0:R1#show pim rp mapping
Wed Mar 23 07:57:43.757 UTC
PIM Group-to-RP Mappings
Group(s) 239.0.0.0/8
RP 10.100.1.1 (?), v2
Info source: 0.0.0.0 (?), elected via config
Uptime: 00:07:39, expires: never
RP/0/0/CPU0:R1#
Summary
Troubleshooting is a learned skill that requires time and effort. To become proficient at solving
multicast problems quickly, you need to understand the infrastructure, establish a baseline, and follow
the fundamental troubleshooting methodology of application, unicast domain, and multicast domain.
The more time you spend reviewing the output of the show commands explained in this chapter, the
better understanding you will have of the operation of multicast. Remember, practice, practice,
practice!
Code Snippets
Code Snippets