Вы находитесь на странице: 1из 1065

Course Presentation Material

Pgina 1 de 2

Last updated 8/27/2001

Finally, the IP Multicast Training materials have been updated with the latest information! Many of you have previously downloaded these materials for the purpose of self-training on IP Multicast. These new course materials have been updated and are even better than before. The training material includes lots of new topics not covered previously in the old course materials. Here's just a sample of some of the changes/additions to the material: Layer 2 Campus Design - Module 2 now contains material on the design issues relating to IP Multicast over campus networks including topics such as CGMP, IGMP Snooping, IGMPv3, mutlicast over ATM-LANE, and general Layer 2 "gotchas" that need to be avoided. Rendezvous Points - Module 6 is devoted to this topic and will help you answer that age old question, "Where do I put my RP?" This module covers the use of various RP techniques such Static RP's, Auto-RP and BSR as well as how to tune and debug these mechanisms. Advanced IP Multicast Features - Module 7 is a module that is chocked full of advanced multicast topics including, IP Multicast Helper, dealing with Rate-Limits, Admin. Scoping and many others. A real "must" read for people that are serious about extracting the absolute maximum performance out of their multicast network Multiprotocol BGP (MBGP) - Module 10 covers the use of MBGP for Inter-domain IP Multicast. Even if you are not already a BGP guru, you will find this module very helpful as it contains a short overview on BGP that will give the beginner to Inter-domain IP Multicasting the necessary background on BGP to get started. Multicast Source Discovery Protocol (MSDP) - Module 11 highlights MSDP and how it is currently being used in the Internet to interconnect independent PIM Sparse mode domains so that true Inter-domain IP Multicast can be accomplished. PIM Protocol Extension - Module 12 is an entirely new module that describes two of the latest extensions to the PIM protocol; Source-Specific Multicast (SSM) and Bidirectional PIM (Bidir). These two new extensions allow PIM to scale better in several different ways. These IP Multicast training modules have previously been used for internal Cisco training only. Due to the tremendous demand for this information, we have made this content available for "self-training" purposes by our customers. All of this material is copyrighted and may not be repackaged or resold for any commercial purposes without written permission from Cisco Systems. All modules are constantly being updated to improve their content and/or correct any mistakes in the material. You may wish to check this page from time to time to download updated versions of the material. The following training modules are all in Adobe PDF format. To view them, use Adobe Acrobat Reader. If file://D:\Lucho\xx\index.html 01/03/2003

Course Presentation Material

Pgina 2 de 2

you don't have Acrobat Reader on your workstation you may download a free version from Adobe. Module Module1 Module2 Module3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12 Title "Fundamentals of IP Multicasting" (1276 KB) "IP Multicasting at Layer 2" (1249 KB) "PIM Dense Mode" (936 KB) "Basic Multicast Debugging" (529 KB) "PIM Sparse Mode" (1599 KB) "Rendezvous Points" (971KB) "Advanced IP Multicast Features" (1319 KB) "DVMRP" (513 KB) "Interconnecting PIM & DVMRP Multicast Networks" (839 KB) "Multi-protocol BGP (MBGP)" (1139 KB) "Multicast Source Discovery Protocol (MSDP)" (1605 KB) "PIM Protocol Extensions" (1053 KB) Updated 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001

file://D:\Lucho\xx\index.html

01/03/2003

Fundamentals of IP Multicast
Module 1

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Module Objectives

Recognize when to use IP Multicast Identify the fundamental concepts involved in IP Multicasting Characterize the differences in various IP Multicast routing protocols

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

2 2

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Agenda

Geekometer

Why Multicast Multicast Applications Multicast Service Model Multicast Distribution Trees Multicast Forwarding Multicast Protocol Basics Multicast Protocol Review
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

3 3

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Why Multicast?

When sending same data to multiple receivers Better bandwidth utilization Less host/router processing Receivers addresses unknown

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

4 4

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Unicast vs Multicast

Unicast
Host Router

Multicast
Host Router
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

5 5

Unicast transmission sends multiple copies of data, one copy for each receiver
Ex: host transmits 3 copies of data and network forwards each to 3 separate receivers Ex: host can only send to one receiver at a time

Multicast transmission sends a single copy of data to multiple receivers


Ex: host transmits 1 copy of data and network replicates at last possible hop for each receiver, each packet exists only one time on any given net work Ex: host can send to multiple receivers simultaneously

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Multicast Advantages
Enhanced Efficiency : Controls network traffic and reduces server and CPU
loads

Optimized Performance: Eliminates traffic redundancy Distributed Applications: Makes multipoint applications possible
Example: Audio Streaming All clients listening to the same 8 Kbps audio

Multicast Unicast 0.8 0.6 Traffic 0.4 Mbps 0.2 0 1

20

40

60

80

100

# Clients
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

6 6

Multicast transmission affords many advantages over unicast transmission in a one-to-many or many-to-many environment
Enhanced Efficiency: available network bandwidth is utilized more efficiently since multiple streams of data are replaced with a single transmission Optimized Performance: less copies of data require forwarding and processing Distributed Applications: multipoint applications will not be possible as demand and usage grows because unicast transmission will not scale Ex: traffic level and clients increase at a 1:1 rate with unicast transmission Ex: traffic level and clients do not increase at a greatly reduced rate with multicast transmission

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Multicast Disadvantages
Multicast is UDP Based!!!
Best Effort Delivery: Drops are to be expected. Multicast applications
should not expect reliable delivery of data and should be designed accordingly. Reliable Multicast is still an area for much research. Expect to see more developments in this area.

No Congestion Avoidance : Lack of TCP windowing and slow-start


mechanisms can result in network congestion. If possible, Multicast applications should attempt to detect and avoid congestion conditions.

Duplicates: Some multicast protocol mechanisms (e.g. Asserts, Registers


and Shortest-Path Tree Transitions) result in the occasional generation of duplicate packets. Multicast applications should be designed to expect occasional duplicate packets.

Out Out- of of-Sequence Packets: Various network events can result in packets
arriving out of sequence. Multicast applications should be designed to handle packets that arrive in some other sequence than they were sent by the source.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

7 7

Multicast Disadvantages
Most Multicast Applications are UDP based. This results in some undesirable sideeffects when compared to similar unicast, TCP applications. Best Effort Delivery results in occasional packet drops. Many multicast applications that operate in real-time (e.g. Video, Audio) can be impacted by these losses. Also, requesting retransmission of the lost data at the application layer in these sort of real-time applications is not feasible. Heavy drops on Voice applications result in jerky, missed speech patterns that can make the content unintelligable when the drop rate gets high enough. Moderate to Heavy drops in Video is sometimes better tolerated by the human eye and appear as unusual artifacts on the picture. However, some compression algorithms can be severely impacted by even low drop rates; causing the picture to become jerky or freeze for several seconds while the decompression algorithm recovers. No Congestion Control can result in overall Network Degradation as the popularity of UDP based Multicast applications grow. Duplicate packets can occasionally be generated as multicast network topologies change. Applications should expect occasional duplicate packets to arrive and should be designed accordingly.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

IP Multicast Applications
Live TV and Radio Broadcast to the Desktop ing Multi e Learn cast Distanc F Data and F i l e T r a n s f er ile Re plica tion Corporate Broadcasts

ing nc e r nfe Co nd Wh o e ema iteb d D i V oar On d/C eo Vid olla bor atio RealReal -Time Data Delivery DeliveryFinancial n
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Training

8/10/2001 3:45 PM

8 8

Many new multipoint applications are emerging as demand for them grows
Ex: Real-time applications include live broadcasts, financial data delivery, whiteboard collaboration, and video conferencing Ex: Non-real-time applications include file transfer, data and file replication, and video-on-demand Note also that the latest version of Novell Netware uses Ipmc for file and print service announcements.see: http//developer.novell.com/research/appnotes/1999/march/02/index.htm

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

Example Multicast Applications Mbone Multicast Applications


sdrsession directory
Lists advertised sessions Launches multicast application(s)

vataudio conferencing
PCM, DVI, GSM, and LPC4 compression

vicvideo conferencing
H.261 video compression

wbwhite board
Shared drawing tool Can import PostScript images Uses Reliable Multicast
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

9 9

Several MBONE multicast applications exist


Ex: Session Directory is a tool that allows participants to view advertised multicast sessions and launch appropriate multicast applications to join an existing session Ex: Audio Conferencing allows multiple participants to share audio interactively Ex: Video Conferencing allows multiple participants to share video and audio interactively Ex: White Boarding allows multiple participants to collaborate interactively in a text and graphical environment

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

sdrSession Directory

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

10 10

SDR - Session Directory (revised)


The SDR tool allows Multimedia multicast sessions to be created by other users in the network. These multimedia sessions (video, audio, etc.) are announced by the SDR application via well-known multicast groups. The window on the left shows an example of the SDR application in action. Each line is a multimedia session that has been created by some user in the network and is being announced (via multicast) by the creators SDR application. By clicking on one of these sessions, the window on the right is brought up. This window displays various information about the multimedia session including: General session information Session schedule Media type (in this case audio and video) Media format Multicast group and port numbers Using the window on the right, one can have SDR launch the appropriate multicast application(s) to join the session.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

10

vatAudio Conferencing

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

11 11

Vat - Audio Conferencing Tool


This is an example of the vat audio conferencing tool. The window on the left is the main window for the session. It contains a speaker gain slider widget and an output VU bar-graph meter along with a microphone gain slider widget and VU meter. When one wishes to address the conference, one usually presses the right mouse button on the workstation. The window on the right is a menu that can be brought up by pressing the Menu button on the main window. This menu allows various parameters about the session to be adjusted including encoding format. Notice that there are several members of this session listed in the main window even though only the second person is talking. (Indicated by the blackened square next to the name.) This points out that all members of the session are multicast sources even though they may never speak and only listed to the session. This is because vat uses the RTP/RTCP model to transport Real-Time audio data. In this model, all members of the session multicast member information and reception statistics to the entire group in an RTCP back-channel . Most all multimedia multicast applications use the RTP/RTCP model including: vat (and its cousin application rat) vic wb - (Whiteboard) IP/TV

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

11

vicVideo Conferencing

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

12 12

vic - Video Conferencing Tool


This is an example of the vic video conferencing tool. The window on the right is the main window for the video conferencing session. Notice that multiple video streams are being received, each with its own thumbnail image. The window on the left is a larger version of the thumbnail image from the main window.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

12

wbWhite Board

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

13 13

wb - Whiteboard
Just as its name implies, this is a form of electronic Whiteboard that can be shared by members of the multicast group.

White Board uses a form of Reliable Multicast


Reliable Multicasting is necessary to insure no loss of critical graphic information occurs. Most multimedia multicast applications simply use UDP, Best Effort datagram delivery mechanisms because of the time critical nature of the media. However, wb needs a reliable method to distribute the graphic images drawn on the electronic Whiteboard.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

13

Downloading MBone Applications


Multimedia conferencing application archive
Contains sdr, vic, vat, rat, wb, nte, and other applications URL:
http://www-mice.cs.ucl.ac.uk/multimedia/software/

Multiple platform support


SunOS, Solaris, HP, Linux, Windows 95/98/2000, Windows NT, etc.

Source code
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

14 14

Several multimedia applications for the MBONE are freely available


- Download the desired application for the appropriate platform - Source code and binaries are available

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

14

IP Multicast Service Model

RFC 1112 (Host Ext. for Multicast Support) Each multicast group identified by a class-D IP address Members of the group could be present anywhere in the Internet Members join and leave the group and indicate this to the routers Senders and receivers are distinct: i.e., a sender need not be a member Routers listen to all multicast addresses and use multicast routing protocols to manage groups

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

15 15

RFC 1112 is the Internet Group Management Protocol (IGMP)


Allows hosts to join a group that receives multicast packets Allows users to dynamically register (join/leave multicast groups) based on applications they execute Uses IP datagrams to transmit data

Addressing
Class D IP addresses (224-239) are dynamically allocated Multicast IP addresses represent receiver groups, not individual receivers

Group Membership
Receivers can be densely or sparsely distributed throughout the Internet Receivers can dynamically join/leave a multicast session at any time using IGMP to manage group membership within the routers Senders are not necessarily included in the multicast group they are sending to Many applications have the characteristic of receivers also becoming senders eg RTCP streams from IP/TV clients and Tibco RV

Multicast Routing
Group distribution requires packet distribution trees to efficiently forward data to multiple receivers Multicast routing protocols effectively direct multicast traffic along network paths Multicast Extension to Open Shortest Path First (MOSPF - 1584) Core Based Tree (CBT)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

15

IP Multicast Service Model


IP group addresses
Class D addresshigh-order 3 bits are set (224.0.0.0) Range from 224.0.0.0 through 239.255.255.255

Well known addresses designated by IANA


Reserved use: 224.0.0.0 through 224.0.0.255
224.0.0.1all multicast systems on subnet 224.0.0.2all routers on subnet
See ftp://ftp. isi.edu/in-notes/ iana/assignments/multicast-addresses

Transient addresses, assigned and reclaimed dynamically


Global scope: 224.0.1.0-238.255.255.255 Limited Scope: 239.0.0.0-239.255.255.255 Site-local scope: 239.253.0.0/16 Organization-local scope: 239.192.0.0/14

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

16 16

IP Addresses use the Class D address space


Class D addresses are denoted by the high 4 bits set to 1110.

Local Scope Addresses


Addresses 224.0.0.0 through 224.0.0.255 Reserved by IANA for network protocol use Eamples: 224.0.0.1 224.0.0.2 224.0.0.3 224.0.0.5 224.0.0.6 All Hosts All Multicast Routers All DVMRP Routers All OSPF Routers All OSPF DR

Multicasts in this range are never forwarded off the local network regardless of TTL Multicasts in this range are usually sent link local with TLL = 1.

Global Scope Addresses


Addresses 224.0.1.0 through 238.255.255.255 Allocated dynamically throughout the Internet

Administratively Scoped Addresses


Addresses 239.0.0.0 through 239.255.255.255 Reserved for use inside of private Domains.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

16

IP Multicast Addressing
Dynamic Group Address Assignment
Historically accomplished using SDR application
Sessions/groups announced over well-known multicast groups Address collisions detected and resolved at session creation time Has problems scaling

Future dynamic techniques under consideration


Multicast Address Set-Claim (MASC)
Hierarchical, dynamic address allocation scheme Extremely complex garbage-collection problem. Long ways off
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

17 17

Dynamic Group Address Assignment


SDR This was typically accomplished using the SDR application which would detect collisions in IP multicast group address assignment at the time new sessions were being created and pick an unused address. While it was sufficient for use on the old MBone when the total number of multicast sessions in the Internet was quite low, SDR has severe scaling problems that preclude it from continuing to be used as the number of sessions increase. Multicast Address Set-Claim (MASC) MASC is new proposal for a dynamic multicast address allocation that is being developed by the malloc Working Group of the IETF. This new proposal will provide for dynamic allocation of the global IP Multicast address space in a hierarchical manner. In this proposal, domains lease IP multicast group address space from their parent domain. These leases are good for only a set period. It is possible that the parent domain may grant a completely different range at lease renewal time due to the need to reclaim address space for use elsewhere in the Internet. As one can imagine, this is a very non-trivial mechanism and is a long ways from actual implementation.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

17

IP Multicast Addressing

Static Group Address Assignment (new)


Temporary method to meet immediate needs Group range: 233.0.0.0 - 233.255.255.255
Your AS number is inserted in middle two octets Remaining low -order octet used for group assignment

Defined in IETF draft


draft-ietf-mboned-glop-addressing -xx.txt

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

18 18

Static Group Address Assignment


Until MASC has been fully specified and deployed, many content providers in the Internet require something to get going in terms of address allocation. This is being addressed with a temporary method of static multicast address allocation. This special allocation method is defined in: draft-ietf-mboned-glop-addressing-xx.txt The basic concept behind this methodology is as follows: Use the 233/8 address space for static address allocation The middle two octets of the group address would contain your AS number The final octet is available for group assignment.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

18

Multicast Protocol Basics

Multicast Distribution Trees Multicast Forwarding Types of Multicast Protocols


Dense Mode Protocols Sparse Mode Protocols

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

19 19

Multicast Distribution Trees


Defines the path down which traffic flows from source to receiver(s).

Multicast Forwarding
Unlike unicast forwarding which uses the destination address to make its forwarding decision, multicast forwarding uses the source address to make its forwarding decision.

Type of Multicast Protocols


Dense Mode Protocols Spares Mode Protocols

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

19

Multicast Distribution Trees

Shortest Path or Source Distribution Tree


Source 1 Notation: (S, G) S = Source G = Group Source 2
A B D F

Receiver 1
Module1. ppt

Receiver 2
8/10/2001 3:45 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

20 20

Shortest Path Trees aka Source Trees


A Shortest path or source distribution tree is a minimal spanning tree with the lowest cost from the source to all leaves of the tree. We forward packets on the Shortest Path Tree according to both the Source Address that the packets originated from and the Group address G that the packets are addressed to. For this reason we refer to the forwarding state on the SPT by the notation (S,G) (pronounced S comma G). where: S is the IP address of the source. G is the multicast group address Example 1: The shortest path between Source 1 and Receiver 1 is via Routers A and C, and shortest path to Receiver 2 is one additional hop via Router E.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

20

Multicast Distribution Trees

Shortest Path or Source Distribution Tree


Source 1 Notation: (S, G) S = Source G = Group Source 2
A B D F

Receiver 1
Module1. ppt

Receiver 2
8/10/2001 3:45 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

21 21

Shortest Path Trees aka Source Trees (cont.)


Every SPT is routed at the source. This means that for every source sending to a group, there is a corresponding SPT. Example 2: The shortest path between Source 2 and Receiver 1 is via Routers D, F and C, and shortest path to Receiver 2 is one additional hop via Router E.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

21

Multicast Distribution Trees

Shared Distribution Tree


Notation: (*, G) * = All Sources G = Group

D (RP)

(RP)

PIM Rendezvous Point Shared Tree

Receiver 1
Module1. ppt

Receiver 2
8/10/2001 3:45 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

22 22

Shared Distribution Trees


Shared distribution tree whose root is a shared point in the network down which multicast data flows to reach the receivers in the network. In PIM -SM, this shared point is called the Rendezvous Point (RP). Multicast traffic is forwarded down the Shared Tree according to just the Group address G that the packets are addressed to, regardless of source address. For this reason we refer to the forwarding state on the shared tree by the notation (*,G) (pronounced star comma G) where: * means any source G is the group address

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

22

Multicast Distribution Trees

Shared Distribution Tree


Source 1 Notation: (*, G) * = All Sources G = Group Source 2
A B D (RP) F

(RP)

PIM Rendezvous Point Shared Tree Source Tree

Receiver 1
Module1. ppt

Receiver 2
8/10/2001 3:45 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

23 23

Shared Distribution Trees (cont.)


Before traffic can be sent down the Shared Tree it must somehow be sent to the Root of the Tree. In classic PIM-SM, this is accomplished by the RP joining the Shortest Path Tree back to each source so that the traffic can flow to the RP and from there down the shared tree. In order to trigger the RP to take this action, it must somehow be notified when a source goes active in the network. In PIM -SM, this is accomplished by first-hop routers (i.e. the router directly connected to an active source) sending a special Register message to the RP to inform it of the active source. In the example above, the RP has been informed of Sources 1 and 2 being active and has subsequently joined the SPT to these sources.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

23

Multicast Distribution Trees Characteristics of Distribution Trees



Source or Shortest Path trees
Uses more memory O(S x G) but you get optimal paths from source to all receivers; minimizes delay

Shared trees
Uses less memory O(G) but you may get sub-optimal paths from source to all receivers; may introduce extra delay

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

24 24

Source or Shortest Path Tree Characteristics


Provides optimal path (shortest distance and minimized delay) from source to all receivers, but requires more memory to maintain

Shared Tree Characteristics


Provides sub-optimal path (may not be shortest distance and may introduce extra delay) from source to all receivers, but requires less memory to maintain

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

24

Multicast Distribution Trees How are Distribution Trees Built?


PIM
Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to build tree.

DVMRP
Uses DVMRP Routing Table plus special Poison-Reverse mechanism to build tree.

MOSPF
Uses extension to OSPFs link state mechanism to build tree.

CBT
Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to build tree.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

25 25

Distribution trees are built in a variety of ways, depending upon the multicast routing protocol employed
PIM utilizes the underlying unicast routing table (any unicast routing protocol) plus: Join: routers add their interfaces and/or send PIM -JOIN messages upstream to establish themselves as branches of the tree when they have interested receivers attached Prune: routers prune their interfaces and/or send PIM-PRUNE messages upstream to remove themselves from the distribution tree when they no longer have interested receivers attached Graft: routers send PIM-GRAFT messages upstream when they have a pruned interface and have already sent PIM-PRUNEs upstream, but receive an IGMP host report for the group that was pruned; routers must reestablish themselves as branches of the distribution tree because of new interested receivers attached DVMRP utilizes a special RIP -like multicast routing table plus: Poison-Reverse: a special metric of Infinity (32) plus the originally received metric, used to signal that the router should be placed on the distribution tree for the source network. Prunes & Grafts: routers send Prunes and Grafts up the distribution similar to PIM-DM. MOSPF utilizies the underlying OSPF unicast routing protocol's link state advertisements to build (S,G) trees Each router maintains an up-to-date image of the topology of the entire network CBT utilizes the underlying unicast routing table and the Join/Prune/Graft mechanisms (much like PIM -SM)
Copyright 1999-2001, Cisco Systems, Inc.
Module1.ppt

25

Multicast Forwarding

Multicast Routing is backwards from Unicast Routing


Unicast Routing is concerned about where the packet is going. Multicast Routing is concerned about where the packet came from.

Multicast Routing uses Reverse Path Forwarding


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

26 26

Multicast Forwarding
Routers must know packet origin, rather than destination (opposite of unicast) ... origination IP address denotes known source ... destination IP address denotes unknown group of receivers Multicast routing utilizes Reverse Path Forwarding (RPF) ... Broadcast: floods packets out all interfaces except incoming from source; initially assuming every host on network is part of multicast group ... Prune: eliminates tree branches without multicast group members; cuts off transmission to LANs without interested receivers ... Selective Forwarding: requires its own integrated unicast routing protocol

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

26

Reverse Path Forwarding (RPF)


What is RPF?
A router forwards a multicast datagram only if received on the up stream interface to the source (I.e. it follows the distribution tree).

The RPF Check


The routing table used for multicasting is checked against the source address in the multicast datagram. If the datagram arrived on the interface specified in the routing table for the source address; then the RPF check succeeds. Otherwise, the RPF Check fails.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

27 27

Reverse Path Forwarding


Routers forward multicast datagrams received from incoming interface on distribution tree leading to source Routers check the source IP address against their multicast routing tables (RPF check); ensure that the multicast datagram was received on the specified incoming interface Note that changes in the unicast topology will not necessarily immediately reflect a change in RPFthis depends on how frequently the RPF check is performed on an Ipmc stream - every 5 seconds is current Cisco default.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

27

Reverse Path Forwarding (RPF)

If the RPF check succeeds, the datagram is forwarded If the RPF check fails, the datagram is typically silently discarded When a datagram is forwarded, it is sent out each interface in the outgoing interface list Packet is never forwarded back out the RPF interface!

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

28 28

Multicast Forwarding
Successful RPF Checks allow the datagram to be forwarded ... Datagram is forwarded out all outgoing interfaces, but not out the RPF interface the datagram was received on Unsuccessful RPF Checks cause the datagram to be silently dropped

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

28

Reverse Path Forwarding (RPF)

Example: RPF Checking

Source 151.10.3.21

Mcast Dist. Tree Mcast Packets

RPF Checks Fail Packets arrived on wrong interface!

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

29 29

Multicast Forwarding: RPF Checking


Source floods network with multicast data Each router has a designated incoming interface (RPF interface) on which multicast data can be received from a given source Each router receives multicast data on one or more interfaces, but performs RPF check to prevent duplicate forwarding

Example: Router receives multicast data on two interfaces


1) performs RPF Check on multicast data received on interface E0; RPF Check succeeds because data was received on specified incoming interface from source 151.10.3.21; data forwarded through all outgoing interfaces on the multicast distribution tree 2) performs RPF Check on multicast data received on interface E1; RPF Check fails because data was not received on specified incoming interface from source 151.10.3.21; data silently dropped

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

29

Reverse Path Forwarding (RPF)

A closer look: RPF Check Fails


Multicast Packet from Source 151.10.3.21

RPF Check Fails!


Unicast Route Table Network Interface 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0

S1 E0

X
S0 S2

Packet Arrived on Wrong Interface! Discard Packet!

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

30 30

Multicast Forwarding: RPF Check Fails


Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1 ... multicast data is silently dropped because it arrived on an interface not specified in the RPF check (S0)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

30

Reverse Path Forwarding (RPF)

A closer look: RPF Check Succeeds


Multicast Packet from Source 151.10.3.21
S0 S1 S2 E0

RPF Check Succeeds!


Unicast Route Table Network Interface 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0

Packet Arrived on Correct Interface! Forward out all outgoing interfaces. (i. e. down the distribution tree)

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

31 31

Multicast Forwarding: RPF Check Succeeds


Ex: Router can only accept multicast data from Source 151.10.3.21 on interface S1 ... multicast data is forwarded out all outgoing on the distribution tree because it arrive on the incoming interface specified in the RPF check (S1)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

31

TTL Thresholds
What is a TTL Threshold?
A TTL Threshold may be set on a multicast router interface to limit the forwarding of multicast traffic to outgoing packets with TTLs greater than the Threshold.

The TTL Threshold Check


1) All incoming IP packets first have their TTL decremented byone. If <= Zero, they are dropped. 2) If a multicast packet is to be forwarded out an interface with a non-zero TTL Threshold; then its TTL is checked against the TTL Threshold. If the packets TTL is < the specified threshold, it is not forwarded out the interface.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

32 32

TTL-Thresholds
Non-Zero, Multicast, TTL-Thresholds may be set on any multicast capable interface. IP multicast packets whose TTLs (after being decremented by one by normal router packet processing) are less than the TTL -Threshold on an outgoing interface, will be not be forwarded out that interface. Zero Multicast TTL implies NO threshold has been set.

TTL-Threshold Application
Frequently used to set up multicast boundaries to prevent unwanted multicast traffic from entering/exiting the network.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

32

TTL Thresholds

A closer look: TTL-Thresholds


Multicast Packet w/TTL = 24
oilist: S1: (TTL-Threshold = 16) E0: (TTL-Threshold = 0) S2: (TTL-Threshold = 64)

TTL-Threshold = 16 S1 E0

S2 TTL-Threshold = 64

TTL-Threshold = 0

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

TTL-Threshold Example
In the above example, the interfaces have been configured with the following TTL Thresholds: S1: TTL -Threshold = 16 E0: TTL -Threshold = 0 (none) S2: TTL -Threshold = 64 An incoming Multicast packet is received on interface S0 with a TTL of 24. The TTL is decremented to 23 by the normal router IP packet processing. The outgoing interface list for this Group contains interfaces S1, E0 & S2. The TTL -Threshold check is performed on each outgoing interface as follows: S1: TTL (23) > TTL -Threshold (16). FORWARD E0: TTL (23) > TTL -Threshold (0). FORWARD

S2: TTL (23) < TTL -Threshold (64). DROP

Copyright 1999-2001, Cisco Systems, Inc.

S0

Packet not forwarded!

8/10/2001 3:45 PM

33 33

Module1.ppt

33

TTL Threshold Boundaries

Company ABC

Eng

Mkt

TTL-Threshold = 16

TTL-Threshold = 128

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

34 34

TTL-Threshold Boundaries
TTL-Thresholds may be used as boundaries around portions of a network to prevent the entry/exit of unwanted multicast traffic. This requires multicast applications to transmit their multicast traffic with an initial TTL value set so as to not cross the TTL -Threshold boundaries. In the example above, the Engineering or Marketing departments can prevent department related multicast traffic from leaving their network by using a TTL of 15 for their multicast sessions. Similarlly, Company ABC can prevent private multicast traffic from leaving their network by using a TTL of 127 for their multicast sessions.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

34

Administrative Boundaries

Administrative Boundary = 239.0.0.0/8

239.x.x.x multicasts
Serial0

239.x.x.x multicasts
Serial1

Configured using the ip multicast boundary <acl> interface command

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

35 35

Administrative Boundaries
Administratively-scoped multicast address ranges may also be used as boundaries around portions of a network to prevent the entry/exit of unwanted multicast traffic. This requires multicast applications to transmit their multicast traffic with a group address that falls within the Administrative address range so that it will not cross the Administrative boundaries. In the example above, the entire Administratively-Scoped address range, (239.0.0.0/8) is being blocked from entering or leaving the router via interface Serial0. This is often done at the border of a network where it connects to the Internet so that potentially sensitive company Administratively-Scoped multicast traffic can leave the network. (Nor can it enter the network from the outside.) Administrative multicast boundaries can be configured in Cisco IOS by the use of the ? ? ? ? ? ? ? ? ? ? ? ? ???????? interface command.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

35

Administrative Boundaries

Company ABC

LA Campus

NYC Campus

239.128.0.0/16

239.129.0.0/16

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

36 36

Administrative Boundaries
Administratively-scoped multicast address ranges generally used in more than one location. In the example above, the Administratively-Scoped address range, (239.128.0.0/16) is being used by both the LA campus and the NYC campus. Multicast traffic originated in these address ranges will remain within each respective campus and not onto the WAN that exists between the two campuses. This is often sort of configuration is often used so that each campus can source high-rate multicasts on the local campus and not worry about it being accidentally leaked into the WAN and causing congestion on the slower WAN links. In addition to the 239.128.0.0/16 range, the entire company network has a Administrative boundary for the 239.129.0.0/16 multicast range. This is so that multicasts in these ranges do not leak into the Internet. Note: The Admin. -Scoped address range (239..0.0/8) is similar to the 10.0.0.0 unicast address range in that it is reserved and is not assigned for use in the Internet.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

36

Types of Multicast Protocols


Dense-mode
Uses Push Model Traffic Flooded throughout network Pruned back where it is unwanted Flood & Prune behavior (typically every 3 minutes)

Sparse-mode
Uses Pull Model Traffic sent only to where it is requested Explicit Join behavior
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

37 37

Dense-mode multicast protocols


Initially flood/broadcast multicast data to entire network, then prune back paths that don't have interested receivers

Sparse-mode multicast protocols


Assumes no receivers are interested unless they explicitly ask for it

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

37

Multicast Protocol Review Currently, there are 4 multicast routing protocols:


? DVMRPv3 (Internet-draft)
DVMRPv1 (RFC1075) is obsolete and was never used.

? MOSPF (RFC 1584) Proposed Standard ? PIM-DM (Internet-draft) ? CBT (Internet-draft) ? PIM-SM (RFC 2362) Proposed Standard
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

38 38

IETF status of Multicast Protocols


DVMRPv1 is obsolete and was never used. DVMRPv2 is an old Internet-Draft and is the current implementation used through-out the Mbone. DVMRPv3 is the current Internet-Draft although it has not been completely implemented by most vendors. MOSPF is currently at Proposed Standard status. However, most members of the IETF IDMR working group doubt that MOSPF will scale to any degree and are therefore uncomfortable with declaring MOSPF as a standard for IP Multicasting. (Even the author of MOSPF, J. Moy, has been quoted in an RFC that, more work needs to be done to determine the scalability of MOSPF.) PIM-DM is in Internet Draft form and work continues to move into an RFC. CBT is also in Internet Draft form and while it has been through three different and incompatible revisions, it is not enjoying significant usage nor is it a primary focus of the IETF IDMR working group. PIM-SM moved to Proposed Standard in early 2000. Much of the effort in the IETF towards a working multicast protocol is focused on PIM -SM.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

38

Dense-Mode Protocols

DVMRP - Distance Vector Multicast Routing Protocol MOSPF - Multicast OSPF PIM DM - Protocol Independent Multicasting (Dense Mode)

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

39 39

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

39

DVMRP Overview
Dense Mode Protocol
Distance vector-based
Similar to RIP Infinity = 32 hops Subnet masks in route advertisements

DVMRP Routes used:


For RPF Check To build Truncated Broadcast Trees (TBTs)
Uses special Poison-Reverse mechanism

Uses Flood and Prune operation


Traffic initially flooded down TBTs TBT branches are pruned where traffic is unwanted. Prunes periodically time-out causing reflooding.
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

40 40

Distance Vector Multicast Routing Protocol


Builds a distribution tree per source network based on best metric (hop-count) back towards the source network. Infinity = 32 hops A Poison Reverse metric is used by DVMRP routers to signal their upstream neighbor that they are downstream and expect to receive traffic from a source network via the upstream router. Poison Reverse is denoted by adding Infinity (32) to the received metric and then sending it back to the router from which it was originally received. When a Poison Reverse is received for a source network, the interface over which it was received is placed on the outgoing interface list for the source network. Multicast traffic is flooded out all interfaces on the outgoing interface list (I.e. down the distribution tree for the source network). Downstream neighbors send Prunes up the distribution tree for multicast traffic for which they have no group members.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

40

DVMRP Source Trees


Source Network S1 Truncated Broadcast Trees Are Built using Best DVMRP Metrics Back to Source Network. Lowest IP Address Used in Case of a Tie. (Note: IP Address of D < C < B < A)

A
mrouted 1 33 1 mrouted 33

B
mrouted 1 2

X
mrouted 3 mrouted 34 35

mrouted 2 2

E
3

35

Y
mrouted

n m

Route for source network of metric n Poison reverse (metric + infinity) sent to upstream parent router. Router depends on parent to receive traffic for this source. Resulting Truncated Broadcast Tree for Source Network
41 41

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

DVMRP Source Trees


DVMRP builds its Source Trees utilising the concept of Truncated Broadcast Trees. The basic definition of a Truncated Broadcast Tree (TBT) is as follows: A Truncated Broadcast Tree (TBT) for source subnet S1, represent a shortest path spanning tree rooted at subnet S1 to all other routers in the network. In DVMRP, the abstract notion of the TBTs for all sub-networks are built by the exchange of periodic DVMRP routing updates between all DVMRP routers in the network. Just like its unicast cousin, RIPv2, DVMRP updates contain network prefixes/masks along with route metrics (in hop-counts) that describe the cost of reaching a particular subnets in the network. Unlike RIPv2, a downstream DVMRP router makes use of a special PoisonReverse advertisement to signal an upstream router that this link is on the TBT for source subnet S1. This Poison-Reverse (PR) is created by adding 32 to the advertised metric and sending back to the upstream router.

Example DVMRP TBT for network S1:


In the above example, DVMRP updates are being exchanged for source network S1. Routers A and B both advertise a metric of 1 (hop) to reach network S1 to routers C and D. In the case of router D, the advertisement from B is the best (only) route to source network S1 which causes router D to send back a PR advertisement (metric = 33) to B. This tells router B that router D is on the TBT for source network S1. In the case or router C, it received an advertisement form both A and B with the same metric. It breaks the tie using the lowest IP address and therefore sends a PR advertisement to router B. B now knows it has two branches of the TBT, one to router C and one to router D. These DVMRP updates flow throughout the entire network causing each router to send PR advertisements to its upstream DVMRP neighbor on the TBT for source network S1.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

41

DVMRP Source Trees

Forwarding onto Multi-access Networks


Network S1 A
mrouted 1 1

Both B & C have routes to network S1. To avoid duplicates, only one router can be Designated Forwarder for network S1. Router with best metric is elected as the Designated Forwarder. Lowest IP address used as tie-breaker. Router C wins in this example.

mrouted

mrouted 2 2

(Note: IP Address of C < B ) n


Module1. ppt

Route advertisement for network S1 of metric n


1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

42 42

Forwarding onto Multi-access Networks


When two or more routers share a common Multi-access network, only one can be the Designated Forwarder which is responsible for forwarding a source networks traffic onto the Multi-access network; otherwise duplicate packets will be generated. The Designated Forwarder is selected based on the best route metric back to the source network (with the Lowest IP Address used as a tie-breaker). In the example above, both Router B and C share a common Multi-access network and each have routes to network S1. Since both have the same metric to network S1, the lowest IP address is used to break the tie (in this case, Router C wins).

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

42

DVMRP Source Trees


Source Network S1 Resulting Truncated Broadcast Tree for Source Network S1

A
mrouted

B
mrouted

X
mrouted

mrouted

mrouted

mrouted

Y
mrouted

S1 Truncated Broadcast Tree


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

43 43

Example DVMRP TBT for network S1 (cont.)


Once the DVMRP network has converged and all PR advertisements have been sent up the TBT toward source network S1, the S1 TBT has been built. The drawing above shows the S1 TBT that resulted in the DVMRP route update exchanges from the previous page. Notice that this is a minimum spanning tree that is rooted at source network S1 and spans all routers in the network. If a multicast source were to now go active in network S1, the DVMRP routers in the network will initially flood this sources traffic down the S1 TBT.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

43

DVMRP Source Trees


Each Source Network has its Own Truncated Broadcast Tree

A
mrouted

B
mrouted

X
mrouted

mrouted

mrouted

mrouted

Y
mrouted

Note: IP Address of D < C < B < A

S2 Truncated Broadcast Tree


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Source Network S2
8/10/2001 3:45 PM

44 44

Every source network has its own TBT


In the drawing above, the TBT for network S2 is shown. This TBT would also be created by the exchange of DVMRP route updates and by PR advertisements sent by all routers in the network toward network S2. It is important to remember that these TBTs simply exist in the form of PR advertisements in the DVMRP routing tables of the routers in the network and as such, there is one TBT for every source network in the DVMRP net work.

Advantages of TBTs
The advantage of TBTs is that the initial flooding of multicast traffic throughout the DVMRP network is limited to flowing down the branches of the TBT. This insures that there are no duplicate packets sent as a result of parallel paths in the network.

Disadvantages of TBTs
The disadvantage of using TBTs is that it requires separate DVMRP routing information to be exchanged throughout the entire network. (Unlike other multicast protocols such as PIM that make use of the existing unicast routing table and do not have to exchange additional multicast routing data. Additionally, because DVMRP is based on a RIP model, it has all of the problems associated with a Distance-Vector protocol including, count-to-infinity, holddown, periodic updates. One has to ask oneself, Would I recommend someone build a unicast network based on RIP today? The answer is of course not, protocols like OSPF, IS-IS, and EIGRP have long since superseded RIP in robustness and scalability. The same is true of DVMRP.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

44

DVMRP Flood & Prune


Source S Initial Flooding of (S, G) Multicast Packets Down Truncated Broadcast Tree

A
mrouted

B
mrouted

X
mrouted

mrouted

mrouted

mrouted

Y
mrouted

Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

45 45

DVMRP Example
In this example we see source S has begun to transmit multicast traffic to group G. Initially, the traffic (shown by the solid arrows) is flooded to all routers in the network down the Truncated Broadcast Tree (indicated by the dashed arrows) and is reaching Receiver 1.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

45

DVMRP Flood & Prune


Source S Routers C is a Leaf Node so it sends an (S, G) Prune Message Router B Prunes interface.

A
mrouted Prune

B
mrouted

X
mrouted

mrouted

mrouted

mrouted

Y
mrouted

Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

46 46

DVMRP Example (cont.)


At this point, we see that router C is a leaf node on the TBT and has no need for the traffic. Therefore, it sends a DVMRP (S, G) Prune message up the TBT to router B to shutoff the unwanted flow of traffic. Router B receives this (S, G) Prune message and shuts off the flow of (S, G) traffic to router C.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

46

DVMRP Flood & Prune


Source S Routers X, and Y are also Leaf Nodes so they send Prune (S, G) Messages Router E prunes interface. Prune

A
mrouted

B
mrouted

X
mrouted

mrouted

mrouted

mrouted

Prune

Y
mrouted

Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

47 47

DVMRP Example (cont.)


Both routers X and Y are also leaf nodes that have no need for the (S, G) traffic (i.e. they have no directly connected receivers) and therefore send (S, G) Prunes up the TBT to router E. Once router E has received (S, G) Prunes messages from all DVMRP neighbours on the subnet it prunes the Ethernet interface connecting to router X and Y.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

47

DVMRP Flood & Prune


Source S Router E is now a Leaf Node; it sends an (S, G) Prune message. Router D prunes interface.

A
mrouted

B
mrouted

X
mrouted Prune

mrouted

mrouted

mrouted

Y
mrouted

Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

48 48

DVMRP Example (cont.)


At this point, all of router Es downstream interfaces on the TB T have been pruned and it no longer has any need for the (S, G) traffic. As a result, it too sends an (S,G) Prune up the TBT to router D. When router D receives this (S, G) Prune, it prunes the interface and shuts off the flow of (S, G) traffic to router E.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

48

DVMRP Flood & Prune


Source S

A
mrouted

B
mrouted

Final Pruned State

X
mrouted

mrouted

mrouted

mrouted

Y
mrouted

Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

49 49

DVMRP Example (cont.)


In the drawing above, we see the final pruned state of the TBT which leaves traffic flowing to the receiver. However, because DVMRP is a flood and prune protocol, these pruned branches of the TBT will time out (typically after 2 minutes) and (S, G) traffic will once again flood down all branches of the TBT. This will again trigger the sending (S, G) Prune messages up the TBT to prune of unwanted traffic.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

49

DVMRP Evaluation

Widely used on the MBONE (being phased out) Significant scaling problems
Slow ConvergenceRIP-like behavior Significant amount of multicast routing state information stored in routers(S,G) everywhere No support for shared trees Maximum number of hops < 32

Not appropriate for large scale production networks


Due to flood and prune behavior Due to its poor scalability

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

50 50

Appropriate for large number of densley distributed receivers located in close proximity to source Widely used, oldest multicast routing protocol Significant scaling problems
Protocol limits maximum number of hops to 32 and requires a great deal of multicast routing state information to be retained

Not appropriate for...


Few interested receivers (assumes everyone wants data initially) Groups sparsely represented over WAN (floods frequently)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

50

MOSPF (RFC 1584)


Extension to OSPF unicast routing protocol
OSPF: Routers use link state advertisements to understand all available links in the network (route messages along least-cost paths) MOSPF: Includes multicast information in OSPF link state advertisements to construct multicast distribution trees (each router maintains an up-to-date image of the topology of the entire network)

Group membership LSAs are flooded throughout the OSPF routing domain so MOSPF routers can compute outgoing interface lists Uses Dijkstra algorithm to compute shortest-path tree
Separate calculation is required for each (S Net, G) pair
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

51 51

Multicast Extension to OSPF (RFC 1584)


Extension to OSPF unicast routing protocol; requires OSPF as underlying unicast routing protocol.

Group Membership LSAs


MOSPF uses a new type of OSPF LSA called Group-Membership LSA to advertise the existence of Group members on networks. Group-Membership LSAs are periodically flooded throughout an area in the same fashion as other OSPF LSAs.

Dijkstra Algorithm
Uses Dijkstra algorithm to compute shortest-path tree for every sourcenetwork/group pair!!!

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

51

MOSPF Membership LSAs


Area 0

MABR1 Area 1

MABR2 Area 2

Membership LSAs

MB

Membership LSAs

MA
Module1. ppt

MB
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

MA
8/10/2001 3:45 PM

52 52

Membership LSA Flooding Example


In this example, Area 1 has members of both Group A and B while Area 2 has members of Group A only. Routers with directly connect members originate Membership LSAs announcing the existence of these members on their networks. These LSAs are flooded throughout the area. Notice that these Group Membership LSAs do not travel between Area 1 and Area 2. (This will be addressed later.)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

52

MOSPF Intra-Area Traffic


Area 0

Not receiving (S2 , A) traffic Area 1

MABR1

MABR2 Area 2

MB

MA
Module1. ppt

M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

M A (S2 , A)
8/10/2001 3:45 PM

53 53

Intra-Area Multicast
Once all routers within the area have learned where all members are in the network topology, it is possible to construct Source-network trees for multicast traffic forwarding.

Example
In the above example, Source S1 in Area 1 begins sending multicast traffic to Group B. As this data reaches the the routers in the area, each runs a Dijkstra calculation and computes a Shortest Path Tree rooted at the network for S1 and that spans all the members of Group B. The results of these calculations are used to forward the (S1, B) traffic as seen in Area 1 above. In Area 2, Source S2 begins sending multicast traffic to Group A. Again, the routers in the area use the Group-Membership information in their MOSPF database to run a Dijkstra calculation for the source network where S2 resides and create a Shortest Path Tree for this traffic flow. The results are then used to forward (S2, A) traffic as shown. Notice that the routers in Area 2 are not aware of the member of Group A in Area 1 because Membership LSAs are not flooded between these two areas. This InterArea traffic flow is handled by another mechanism that is described in the next few pages.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

53

MOSPF Inter-Area Traffic


Wildcard Receivers pull traffic from all sources in the area.
Wildcard Receiver Flag

Area 0

Wildcard Receiver Flag

(*, *)

(*, *)

MABR1 Area 1

MABR2 Area 2

MB

MA
Module1. ppt

M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

M A (S2 , A)
8/10/2001 3:45 PM

54 54

Wildcard Receivers
In order to get multicast traffic to flow between Areas, the concept of Wildcard Receivers is used by MOSPF Area Border Routers (MABR). Wildcard Receivers set the Wildcard Receiver flag is in the Router LSAs that they inject into the Area. This flag is equivalent to a wildcard Group Membership LSA that effectively says, I have a directly connected member for every group.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

54

MOSPF Inter-Area Traffic


Area 0

MABR1 Area 1

MABR2 Area 2

MB

MA
Module1. ppt

M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

M A (S2 , A)
8/10/2001 3:45 PM

55 55

Multicast Area Border Routers (MABR)


Multicast Area Border routers (i.e. routers that connect an area to the backbone area, Area 0) , always set the Wildcard Receiver flag in their Router LSAs that they are injecting into a non-backbone area. This causes the MABR to be always be added as a branch of the Shortest Path Tree of any active source in the non-backbone area. In the above example, this has resulted in MABR1 being added to the SPT for (S1,B) traffic and MABR2 being added to the SPT for (S2, A) traffic. This pulls the source traffic in the area to the border router so that it can be sent into the backbone area.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

55

MOSPF Inter-Area Traffic


Area 0 MABR routers inject Summary Membership LSAs into Area 0. (GA , GB)
Summarized Membership LSA

(GA )
Summarized Membership LSA

MABR1 Area 1

MABR2 Area 2

Membership LSAs

MB

Membership LSAs

MA
Module1. ppt

M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

M A (S2 , A)
8/10/2001 3:45 PM

56 56

Summary Membership LSAs


In addition to Group Membership LSAs MOSPF also defines a new Summary Membership LSA that is used to summarise an areas group membership information. Summary Membership LSAs are injected into the backbone area, Area 0 so that routers in the backbone area are made aware of the existence of members in other areas.

Inter-Area Traffic Example


In the above example, the existence of members of groups A and B in Area 1 is being injected into the backbone area by MABR1 via Summary Membership LSA. In addition, MABR2 is injecting a Summary Membership LSA into the backbone area that indicates that Area 2 has members of group A. Routers in the backbone area now use the information in these Summary Membership LSAs in their Dijkstra calculations to know which MABRs to include in the backbone SPT for which sources. (See next drawing.)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

56

MOSPF Inter-Area Traffic


Area 0

MABR1 Area 1

MABR2 Area 2

MB

MA
Module1. ppt

M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

M A (S2 , A)
8/10/2001 3:45 PM

57 57

Inter-Area Traffic Example


The combination of the Wildcard Receiver mechanism and the injection of Summary Membership LSAs into the backbone area permits the SPT for (S2,A) traffic to be extended across the backbone area. (S2, A) traffic is now flowing from Area 2 and into the backbone area (Area 0) via MABR2. The routers in the backbone are forwarding this traffic to MABR1 who is sending the traffic into Area 1. Routers inside of Area 1 run the Dijkstra calculation on (S2, A) traffic and construct an (S2, A) SPT inside of Area 1 to route the traffic to members of group A as shown above.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

57

MOSPF Inter-Area Traffic


Area 0 Unnecessary traffic still flowing to the MABR Routers!!
Wildcard Receiver Flag Wildcard Receiver Flag

(*, *)

(*, *)

MABR1 Area 1

MABR2 Area 2

(S1 , B)
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

(S2 , A)
8/10/2001 3:45 PM

58 58

Unnecessary Traffic Flows


In the case where there are no members for a multicast group, traffic is still pulled to the MABRs as a result of the Wildcard Receiver mechanisms. This can result in bandwidth being consumed inside of the area unnecessarily.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

58

MOSPF Inter-Domain Traffic


Area 0
Summarized Membership LSA

MASBR

External AS
Summarized Membership LSA

(GA , GB)

(GA )

MABR1 Area 1

MABR2 Area 2

Membership LSAs

MB

Membership LSAs

MA
Module1. ppt

MB
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

MA
8/10/2001 3:45 PM

59 59

Inter-Domain Traffic
Inter-domain multicast traffic flow basically follows the same mechanisms that were used for Inter-Area traffic flows. Summary Membership LSAs inform the routers in the backbone of which MABRs has members of which groups.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

59

MOSPF Inter-Domain Traffic


Area 0 MASBR External AS (S1 , A) (S2 , B)

MABR1 Area 1

MABR2 Area 2

MB

MA
Module1. ppt

MB
1998 2001, Cisco Systems, Inc. All rights reserved.

MA

MA
8/10/2001 3:45 PM

60 60

Inter-domain Traffic (cont.)


When traffic arrives from outside the domain via the Multicast AS Border Router (MASBR), this traffic is forwarded across the backbone to the MABRs as necessary based on the Summary Membership LSAs that they have injected into the area. This causes the multicast traffic for group A and B arriving from outside the AS to be forwarded as shown above.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

60

MOSPF Inter-Domain Traffic


Area 0 Unnecessary traffic may flow all the way to the MASBR Router!!
Wildcard Receiver Flag Wildcard Receiver Flag

MASBR

External AS

(*, *)

(*, *)

MABR1 Area 1

MABR2 Area 2

(S1 , B)
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

(S2 , A)
8/10/2001 3:45 PM

61 61

Inter-Domain Traffic (cont.)


MASBRs also use the Wildcard Receiver mechanism to automatically pull all source traffic in the area to them so that they can forward this traffic as needed to the outside world. In the example above, the Wildcard Receiver mechanism is causing the (S1,B) and (S2,A) traffic to be pulled into the backbone area and from there to the MASBR so that it can be forwarded to the outside world.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

61

MOSPF Evaluation
Does not flood multicast traffic everywhere to create state, Uses LSAs and the link-state database Protocol dependentworks only in OSPF-based networks Significant scaling problems
Dijkstra algorithm run for EVERY multicast (S Net, G) pair! Dijkstra algorithm rerun when:
Group Membership changes Line-flaps

Does not support shared-trees

Not appropriate for


General purpose multicast networks where the number of senders may be quite large.
IP/TV - (Every IP/TV client is a multicast source)
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

62 62

Appropriate for use within single routing domain Requires OSPF as underlying unicast routing protocol Significant scaling problems
Frequent flooding of link-state/membership information hinders performance Router CPU demands grow rapidly to keep track of current network topology (source-group pairs) Dijkstra algorithm must be run for every single multicast source Volatility of multicast groups can be lethal

Not appropriate for...


Networks with unstable links (too much Dijkstra algorithm computing required for each source) Many simultaneous active source-network/group pairs (routers must maintain too much information relating to the entire network topoloty) Ubiquitous Multicast Applications permit any user in the network to create an new source-group pair. There is no way for Network Administrator to control the number of sourcenetwork/group pairs in the network!!! Therefore, the Network Administrator has little control to prevent MOSPF from melting down his/her network as multicast applications become popular with the Users!!!

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

62

PIM-DM
Protocol Independent
Supports all underlying unicast routing protocols including: static, RIP, IGRP, EIGRP, IS-IS, BGP, and OSPF

Uses reverse path forwarding


Floods network and prunes back based on multicast group membership Assert mechanism used to prune off redundant flows

Appropriate for...
Smaller implementations and pilot networks
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

63 63

Protocol Independent Multicast (PIM) Dense-mode (Internet-draft)


Uses Reverse Path Forwarding (RPF) to flood the network with multicast data, then prune back paths based on uninterested receivers Interoperates with DVMRP

Appropriate for
Small implementations and pilot networks

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

63

PIM-DM Flood & Prune

Initial Flooding

Source

Multicast Packets

(S, G) State created in every router in the network!

Receiver
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

64 64

PIM-DM Initial Flooding


PIM-DM is similar to DVMRP in that it initially floods multicast traffic to all parts of the network. However unlike DVMRP, which pre-builds a Truncated Broadcast Tree that is used for initial flooding, PIM-DM initially floods traffic out ALL non RPF interfaces where there is: Another PIM-DM neighbor or A directly connected member of the group The reason that PIM-DM does not use Truncated Broadcast Trees to pre-build a spanning tree for each source network is that this would require running a separate routing protocol as does DVMRP. (At the very least, some sort of Poison-Reverse messages would have to be sent to build the TBT.) Instead, PIM-DM uses other mechanisms to prune back the traffic flows and build Source Trees.

Initial Flooding Example


In this example, multicast traffic being sent by the source is flooded throughout the entire network. As each router receives the multicast traffic via its RPF interface (the interface in the direction of the source), it forwards the multicast traffic to all of its PIM-DM neighbors. Note that this results in some traffic arriving via a non-RPF interface such as the case of the two routers in the center of the drawing. (Packets arriving via the nonRPF interface are discarded.) These non-RPF flows are normal for the initial flooding of data and will be corrected by the normal PIM-DM pruning mechanism.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

64

PIM-DM Flood & Prune

Pruning unwanted traffic

Source

Multicast Packets Prune Messages Receiver


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

65 65

Pruning unwanted traffic


In the example above, PIM Prunes (denoted by the dashed arrows) are sent to stop the flow of unwanted traffic. Prunes are sent on the RPF interface when the router has no downstream members that need the multicast traffic. Prunes are also sent on non-RPF interfaces to shutoff the flow of multicast traffic that is arriving via the wrong interface (i.e. traffic arriving via an interface that is not in the shortest path to the source.) An example of this can be seen at the second router from the receiver near the center of the drawing. Multicast traffic is arriving via a non-RPF interface from the router above (in the center of the network) which results in a Prune message.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

65

PIM-DM Flood & Prune

Results after Pruning

Source

Multicast Packets

(S, G) State still exists in every router in the network!

Flood & Prune process repeats every 3 minutes!!!


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Receiver
8/10/2001 3:45 PM

66 66

Results after Pruning


In the final drawing in our example shown above, multicast traffic has been pruned off of all links except where it is necessary. This results in a Shortest Path Tree (SPT) being built from the Source to the Receiver. Even though the flow of multicast traffic is no longer reaching most of the routers in the network, (S, G) state still remains in ALL routers in the network. This (S, G) state will remain until the source stops transmitting. In PIM -DM, Prunes expire after three minutes. This causes the multicast traffic to be re-flooded to all routers just as was done in the Initial Flooding drawing. This periodic (every 3 minutes) Flood and Prune behavior is normal and must be taken into account when the network is designed to use PIM -DM.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

66

PIM-DM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check)

S0 Assert <distance, metric> 2 E0 1

S0 E0 2 Assert <distance, metric>

1 Routers receive packet on an interface in their oilist !!

Only one router should continue sending to avoid


duplicate packets.
2

Routers send PIM Assert messages


Compare distance and metric values Router with best route to source wins If metric & distance equal, highest IP adr wins Losing router stops sending (prunes interface)

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

67 67

PIM Assert Mechanism


The PIM Assert mechanism is used to shutoff duplicate flows onto the same multiaccess network. Routers detect this condition when they receive an (S, G) packet via a multiaccess interface that it is in the (S, G) OIL. This causes the routers to send Assert Messages. Assert messages containing the Admin. Distance and metric to the source combined into a single assert value. (The Admin. Distance is the high-order part of this assert value.) Routers compare these values to determine who has the best path (lowest value) to the source. (If both values are the same, the highest IP address is used as the tie breaker.) The Losing routers (the ones with the higher value) Prunes its interface while the winning router continues to forward multicast traffic onto the LAN segment.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

67

Potential PIM-DM Route Loop Normal Steady-State Traffic Flow

Source
Interface previously Pruned by Assert Process

RPF Interface

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

68 68

Potential PIM-DM Route Loops


The non-deterministic behavior of PIM -DM along with its flood-and-prune mechanism can sometimes result in serious network outages including blackholes and multicast route loops. The network in the above example is a simplified version of a frequently used network design whereby multiple routers are used to provide redundancy in the network. Under normal steady -state conditions, traffic flows from the source via the RPF interfaces as shown. Note that the routers have performed the Assert process and one interface on one router is in the pruned state.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

68

Potential PIM-DM Route Loop Interface Fails X


Source
This Router converges first

RPF Interface

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

69 69

Potential PIM-DM Route Loops


Now lets assume that the forwarding interface of the first-hop router fails as shown above. Lets also assume that the unicast routing of router on the left converges first and PIM computes the new RPF interface as shown.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

69

Potential PIM-DM Route Loop New Traffic Flow X


Source
But wait . . . This Router still hasnt converged yet

Multicast Route Loop ! !


RPF Interface

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

70 70

Potential PIM-DM Route Loops


Unfortunately, the middle router has not yet converged and is still forwarding multicast traffic using the old RPF interface. At this point, a multicast route loop exists in the network due to the transient condition of the two routers having opposite RPF interfaces. During the time that this route loop exists, virtually all of the bandwidth on the network segments can be consumed. This situation will continue until the router in the middle of the picture finally converges and the new correct RPF interface is calculated. Unfortunately, if the router needs some bandwidth to complete this convergence (as in the case when EIGRP goes active), then this condition will never be resolved!

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

70

PIM-DM Assert Problem

Initial Flow
Duplicate Traffic

Receiver

Receiver

Multicast Packets

Source
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

71 71

PIM-DM Assert Problem


While the PIM Assert mechanism is effective in pruning off duplicate traffic, it is not without its weaknesses. Consider the above example where duplicate traffic is flowing onto a LAN segment.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

71

PIM-DM Assert Problem

Sending Asserts
Loser

Receiver

Receiver

Winner

Multicast Packets Assert Messages Source


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

72 72

PIM-DM Assert Problem


The normal PIM Assert mechanism takes place and the two routers exchange routing metrics to determine which one has the best route to the source. In this case, the bottom router has the best metric and is the Assert Winner.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

72

PIM-DM Assert Problem

Assert Loser Prunes Interface


Loser

Receiver

Receiver

Winner

Multicast Packets

Source
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

73 73

PIM-DM Assert Problem


The normal PIM Assert mechanism takes place and the Assert Winner continues forwarding while the Assert Loser prunes its interface and starts its prune timer.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

73

PIM-DM Assert Problem

Assert Winner Fails


Traffic flow is cutoff until Prune times out on Assert Loser. Loser

Receiver

Receiver

X
Winner Multicast Packets Source
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

74 74

PIM-DM Assert Problem


Lets now assume that the Assert Winner fails immediately after winning the Assert process. Unfortunately, the Assert Loser has no way of knowing that the Assert Winner has failed and will wait 3 minutes before timing out its pruned interface. This results in a 3 minute (worst-case) loss of traffic.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

74

PIM-DM Evaluation
Most effective for small pilot networks Advantages:
Easy to configuretwo commands Simple flood and prune mechanism

Potential issues...
Inefficient flood and prune behavior Complex Assert mechanism Mixed control and data planes
Results in (S, G) state in every router in the network Can result in non-deterministic topological behaviors

No support for shared trees


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

75 75

Evaluation: PIM Dense-mode


Most effective for small pilot networks. Advantages Minimal number of commands required for configuration (two) Simple mechanism for reaching all possible receivers and eliminating distribution to uninterested receivers Simple behavior is easier to understand and therefore easier to debug Interoperates with DVMRP Potential issues Necessity to flood frequently because prunes expire after 3 minutes.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

75

Sparse-Mode Protocols

PIM SM- Protocol Independant Multicasting (Sparse Mode) CBT - Core Based Trees

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

76 76

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

76

PIM-SM (RFC 2362)


Supports both source and shared trees
Assumes no hosts want multicast traffic unless they specifically ask for it

Uses a Rendezvous Point (RP)


Senders and Receivers rendezvous at this point to learn of each others existence.
Senders are registered with RP by their first-hop router. Receivers are joined to the Shared Tree (rooted at the RP) by their local Designated Router (DR).

Appropriate for
Wide scale deployment for both densely and sparsely populated groups in the enterprise Optimal choice for all production networks regardless of size and membership density.
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

77 77

Protocol Independent Multicast (PIM) Sparse-mode (RFC 2362)


Utilizes a rendezvous point (RP) to coordinate forwarding from source to receivers Regardless of location/number of receivers, senders register with RP and send a single copy of multicast data through it to registered receivers Regardless of location/number of sources, group members register to receive data and always receive it through the RP Appropriate for Wide scale deployment for both densely and sparsely populated groups in the Enterprise Optimal choice for all production networks regardless of size and membership density.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

77

PIM-SM Shared Tree Joins

RP

( * , G) Joins Shared Tree Receiver

( * , G) State created only along the Shared Tree.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

78 78

PIM-SM Shared Tree Joins


In this example, there is an active receiver (attached to leaf router at the bottom of the drawing) has joined multicast group G. The leaf router knows the IP address of the Rendezvous Point (RP ) for group G and when it sends a (*,G) Join for this group towards the RP. This (*, G) Join travels hop-by-hop to the RP building a branch of the Shared Tree that extends from the RP to the last-hop router directly connected to the receiver. At this point, group G traffic can flow down the Shared Tree to the receiver.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

78

PIM-SM Sender Registration

Source

RP

(S, G) Register (S, G) Joins Shared Tree Source Tree

(unicast)

(S, G) State created only along the Source Tree.

Receiver

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

79 79

PIM-SM Sender Registration


As soon as an active source for group G sends a packet the leaf router that is attached to this source is responsible for Registering this source with the RP and requesting the RP to build a tree back to that router. The source router encapsulates the multicast data from the source in a special PIM SM message called the Register message and unicasts that data to the RP. When the RP receives the Register message it does two things It de-encapsulates the multicast data packet inside of the Register message and forwards it down the Shared Tree. The RP also sends an (S,G) Join back towards the source network S to create a branch of an (S, G) Shortest-Path Tree. This results in (S, G) state being created in all the router along the SPT, including the RP.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

79

PIM-SM Sender Registration

Source

RP

(S, G) Register (S, G) Joins Shared Tree Source Tree (S, G) Register-Stop

(unicast)

RP sends Register-Stop back to first-hop router.

(unicast)

Receiver

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

80 80

PIM-SM Sender Registration (cont.)


As soon as the SPT is built from the Source router to the RP, multicast traffic begins to flow natively from source S to the RP. Once the RP begins receiving data natively (i.e. down the SPT) from source S it sends a Register Stop to the sources first hop router to inform it that it can stop sending the unicast Register messages.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

80

PIM-SM Sender Registration

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

Source traffic flows natively along SPT to RP. From RP, traffic flows down the Shared Tree to Receivers.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

81 81

PIM-SM Sender Registration (cont.)


At this point, multicast traffic from the source is flowing down the SPT to the RP and from there, down the Shared Tree to the receiver.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

81

PIM-SM SPT Switchover

Source

RP

Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes Additional (S, G) State is created along new part of the Source Tree. Receiver Additional (S, G) State is created along along the Shared Tree to prune off (S, G) traffic.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

82 82

PIM-SM Shortest-Path Tree Switchover


PIM-SM has the capability for last-hop routers (i.e. routers with directly connected members) to switch to the Shortest-Path Tree and bypass the RP if the traffic rate is above a set threshold called the SPT-Threshold. The default value of the SPT-Threshold in Cisco routers is zero. This means that the default behaviour for PIM-SM leaf routers attached to active receivers is to immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared tree. In the above example, the last-hop router (at the bottom of the drawing) sends an (S, G) Join message toward the source to join the SPT and bypass the RP. This (S, G) Join messages travels hop-by-hop to the first-hop router (i.e. the router connected directly to the source) thereby creating another branch of the SPT. This also creates (S, G) state in all the routers along this branch of the SPT. Finally, special (S, G)RP-bit Prune messages are sent up the Shared Tree to prune off this (S,G) traffic from the Shared Tree. If this were not done, (S, G) traffic would continue flowing down the Shared Tree resulting in duplicate (S, G) packets arriving at the receiver.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

82

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

(S, G) Traffic flow is now pruned off of the Shared Tree and is flowing to the Receiver via the SPT.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

83 83

PIM-SM Shortest-Path Tree Switchover


At this point, (S, G) traffic is now flowing directly from the first -hop router to the last-hop router and from there to the receiver. Note: The RP will normally send (S, G) Prunes back toward the source to shutoff the flow of now unnecessary (S, G) traffic to the RP IFF it has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree. (This step has been omitted from the example above.) As a result of this SPT-Switchover mechanism, PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

83

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree (S, G) Prune Receiver

(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.

Module1.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

84 84

PIM-SM Shortest-Path Tree Switchover


At this point, the RP no longer needs the flow of (S, G) traffic since all branches of the Shared Tree (in this case there is only one) have pruned off the flow of (S, G) traffic. As a result, the RP will send (S, G) Prunes back toward the source to shutoff the flow of the now unnecessary (S, G) traffic to the RP Note: This will occur IFF the RP has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

84

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

(S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree.

Module1.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

85 85

PIM-SM Shortest-Path Tree Switchover


As a result of the SPT-Switchover, (S, G) traffic is now only flowing from the first-hop router to the last-hop router and from there to the receiver. Notice that traffic is no longer flowing to the RP. As a result of this SPT-Switchover mechanism, it is clear that PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

85

PIM-SM FFF

PIM-SM Frequently Forgotten Fact


The default behavior of PIM-SM is that routers with directly connected members will join the Shortest Path Tree as soon as they detect a new multicast source.

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

86 86

Frequently Forgotten Fact


Unless configured otherwise, the default behaviour of Cisco routers running PIM SM is for last-hop routers to immediately switch to the SPT for any new source.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

86

PIM-SM Evaluation

Effective for sparse or dense distribution of multicast receivers Advantages:


Traffic only sent down joined branches Can switch to optimal source-trees for high traffic sources dynamically Unicast routing protocol-independent Basis for inter-domain multicast routing
When used with MBGP and MSDP

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

87 87

Evaluation: PIM Sparse-mode


Can be used for sparse of dense distribution of multicast receiv ers (no necessity to flood) Advantages Traffic sent only to registered receivers that have explicity joined the multicast group RP can be switched to optimal shortest-path-tree when high-traffic sources are forwarding to a sparsely distributed receiver group Interoperates with DVMRP Potential issues Requires RP during initial setup of distribution tree (can switch to shortest-pathtree once RP is established and determined suboptimal)

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

87

CBT Overview
Constructs single, shared delivery tree (not source -based) for multicast group members
Traffic is sent and received over same tree, regardless of source(s) Reduced amount of multicast state information stored in routers

Uses core router to construct shared tree


Routers send join message to core and form branch of tree, suppressing downstream join messages Downstream routers connect to shared tree through on-tree routers Source unicasts data to core, then multicasts using group ID Aggregates traffic onto smaller subset of links

No Commercial implementation available


Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

88 88

Core Based Trees (Internet-draft)


Utilizes shared delivery tree constructed around core router (much like PIM's RP) Unlike PIM, the Shared tree is bi-directional. If the first-hop router for a source is already on the tree, it forwards the multcast packets out all branches of the tree. If the first-hop router for a source is not on the Shared tree, a single copy of multicast data is sent through the core router to receivers. Regardless of location/number of sources, group members always receive multicast data through through the Shared tree. Key benefits Reduced amount of multicast state information stored in routers (always send and receive over same distribution tree) Traffic is aggregated onto smaller subset of links

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

88

CBT Evaluation

Academic work-in-progress Runs primarily on MS Power Point

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

89 89

Evaluation: CBT
Appropriate for inter- and intra-domain multicast routing (no necessity to flood) Current Deployment New protocol that is not widely deployed in production environments (no commercial implementation available) Improves scalability of some existing multicast algorithms to support sparse distribution of multicast receivers Interoperates with DVMRP Potential issue Has no capability to switch to SPT Can suffer from latency problems since traffic must flow through the Core router. Core routers can become bottlenecks if not selected with great care, especially when senders and receivers are located very far from each other

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

89

Protocol Summary

CONCLUSION
Virtually all production networks should be configured to run PIM in Sparse mode!

Module1. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 3:45 PM

90 90

Protocol Summary
Given the pros and cons of all the multicast routing protocols available, virtually all production networks should be configured to run PIM SM.

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

90

Module1.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

91

Copyright 1999-2001, Cisco Systems, Inc.

Module1.ppt

91

IP Multicasting at Layer 2
Module 2

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Module Objectives
Understand Layer 2 Multicast Addressing Identify the purpose of IGMP Recognize the difference between v1, v2 & v3 of the IGMP protocol Identify issues in IGMP v1-v2 Interoperation Identify potential solutions to L2 Multicast Frame Switching problems
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

2 2

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Module Agenda

MAC Layer Multicast Addresses IGMPv1 IGMPv2 IGMP v1-v2 Interoperability IGMPv3 L2 Multicast Frame Switching

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

3 3

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Layer 3 Multicast Addressing


IP group addresses 224.0.0.0239.255.255.255 Class D addresses = high order bits of 1110 Special reserved group addresses: 224.0.0.0224.0.0.255:
224.0.0.1 224.0.0.2 224.0.0.4
Module2. ppt

All systems on this subnet All routers on this subnet DVMRP routers
8/9/2001 4:20 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

4 4

IANA Reserved Addresses


IANA is the responsible Authority for the assignment of reserved class D addresses. Other interesting reserved addresses are: 224.0.0.2 - PIMv1 (ALL-ROUTERS - due to transport in IGMPv1) 224.0.0.5 - OSPF ALL ROUTERS 224.0.0.6 - OSPF DESIGNATED ROUTERS 224.0.0.9 - RIP2 Routers 224.0.0.13 - PIMv2 224.0.1.39 - CISCO-RP-ANNOUNCE 224.0.1.40 - CISCO-RP-DISCOVERY (Auto-RP) (Auto-RP) (RFC1583) (RFC1583)

ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses is the authoritative source for reserved multicast addresses.

Additional Information
"Administratively Scoped IP Multicast", June 1997, has a good discussion on scoped addresses. This document is available at: draft-ietf-mboned-admin-ip-space-03.txt

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Layer 2 Multicast Addressing IP Multicast MAC Address Mapping


(FDDI and Ethernet)
32 Bits 1110 28 Bits

239.255.0.1
5 Bits Lost

01-00-5e-7f-00-01
25 Bits 48 Bits 23 Bits

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

5 5

Ethernet & FDDI Multicast Addresses


The low order bit (0x01) in the first octet indicates that this packet is a Layer 2 multicast packet. Furthermore, the 0x01005e prefix has been reserved for use in mapping L3 IP multicast addresses into L2 MAC addresses. When mapping L3 to L2 addresses, the low order 23 bits of the L3 IP multicast address are mapped into the low order 23 bits of the IEEE MAC address. Notice that this results in 5 bits of information being lost.

A bit of History
It turns out that this loss of 5 bits worth of information was not originally intended. When Dr. Steve Deering was doing his seminal research on IP Multicast, he approached his advisor with the need for 16 OUIs to map all 28 bits worth of Layer 3 IP Multicast address into unique Layer 2 MAC addresses. Note: An OUI (Organizationally Unique Identifier) is the high 24 bits of a MAC address that is assigned to an organization by the IEEE. A single OUI therefore provides 24 bits worth of unique MAC addresses to the organization. Unfortunately, at that time the IEEE charged $1000 for each OUI assigned which meant that Dr. Deering was requesting that his advisor spend $16,000 so he could continue his research. Due to budget constraints, the advisor agreed to purchase a single OUI for Dr. Deering. However, the advisor also chose to reserve half of the MAC addresses in this OUI for other graduate research projects and granted Dr. Deering the other half. This resulted in Dr. Deering having only 23 bits worth of MAC address space with which to map 28 bits of IP Multicast addresses. (Its too bad that it wasnt known back then how popular IP Multicast would become. If they had, Dr. Deering might have been able to pass the hat around to interested parties and collected enough money to purchase all 16 OUIs. :-) )
Copyright ? ?1998-2001 Cisco Systems, Inc.
Module2.ppt

Layer 2 Multicast Addressing IP Multicast MAC Address Mapping


(FDDI & Ethernet)

Be Aware of the 32:1 Address Overlap


32 - IP Multicast Addresses 224.1.1.1 224.129.1.1 225.1.1.1 225.129.1.1 . . . 238.1.1.1 238.129.1.1 239.1.1.1 239.129.1.1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

1 - Multicast MAC Address (FDDI and Ethernet)

0x0100.5E01.0101

8/9/2001 4:20 PM

6 6

L2/L3 Multicast Address Overlap


Since there are 28 bits of unique address space for an IP multicast address (32 minus the first 4 bits containing the 1110 Class D prefix) and there are only 23 bits plugged into the IEEE MAC address - there are 5 bits of overlap or 28-23 = 5. 2**5 = 32 therefore there is a 32:1 overlap of L3 addresses to L2 addresses so beware several L3 addresses can map to the same L2 multicast address! For example, all of the following IP multicast addresses map to the same L2 multicast of 01-00-5e-0a-00-01: 224.10.0.1, 225.10.0.1, 226.10.0.1, 227.10.0.1 228.10.0.1, 229.10.0.1, 230.10.0.1, 231.10.0.1 232.10.0.1, 233.10.0.1, 234.10.0.1, 235.10.0.1 236.10.0.1, 237.10.0.1, 238.10.0.1, 239.10.0.1 224.138.0.1, 225.138.0.1, 226.138.0.1, 227.138.0.1 228.138.0.1, 229.138.0.1, 230.138.0.1, 231.138.0.1 232.138.0.1, 233.138.0.1, 234.138.0.1, 235.138.0.1 236.138.0.1, 237.138.0.1, 238.138.0.1, 239.138.0.1

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Layer 2 Multicast Addressing IP Multicast MAC Address Mapping


(Token Ring)
A Layer 3 IPmc Address Maps to a single Token Ring Functional Address or the all ones Broadcast address:

224.x.x.x c0-00-00-04-00-00
(Shown in Token Ring, non-canonical format)

224.x.x.x ff-ff-ff-ff-ff-ff

Results in high levels of unwanted interrupts for nonnon-interested Hosts


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

7 7

Token Ring MAC Addresses


Because the bit order of bytes transmitted on Token-Ring are reversed, it is typical to see Token Ring MAC addresses written in their non-canonical form. For example, when transposed to canonical (Ethernet) form, the 0xc000.0004.0000 MAC address in the above slide would be 0x0300.0020.0000.

Token Ring Functional Addresses


Token Ring Functional Addresses use a format of 0xc000.0004.xxxx where the last 2 octets typically has at most, a single bit set. Many of the Functional Addresses are reserved for well-known Token-Ring MAC layer functions such as Ring Error Monitor and others. A bit in the 3rd Octet is used to signal that this is a Functional Address. In fact, the 0x5e (canonical form) in the 3rd Octet of a normal Ethernet multicast address has a bit pattern that would confuse Token Ring end stations into thinking that the address was a Functional Address. Therefore, IP multicast address to L2 multicast address mapping cannot occur in Token Ring as it does in Ethernet.

Impact on Token-Ring End Stations


Mapping all multicast addresses into a single L2 address forces the the main CPU in end systems to perform filtering of wanted vs. unwanted multicast packets instead of being handled in hardware by the Token Ring NIC card. This creates significant performance issues on Token-Ring end systems when multicasting traffic is present on the ring. This is a very good reason, among many others, for users considering the Ethernet versus Token Ring debate to strongly consider Ethernet if MultiMedia Applications and IPmc is being deployed or planned.
Copyright ? ?1998-2001 Cisco Systems, Inc.
Module2.ppt

Layer 2 Multicast Addressing IP Multicast MAC Address Mapping


(Token Ring)

Be Aware of the 268,435,200:1 Address Overlap


ALL 268,435,200 - IP Multicast Addresses 224.0.1.0 224.0.1.1 224.0.1.2 224.0.1.3 . . . 239.239.255.252 239.255.255.253 239.255.255.254 239.255.255.255
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

1 - Multicast MAC Address (Token Ring)

0xFFFF.FFFF.FFFF

RUN AWAY ! ! !
8/9/2001 4:20 PM

8 8

L2/L3 Multicast Address Overlap


Unfortunately, all 28 significant bits of an IP multicast address (32 minus the first 4 bits) map into a single Token Ring MAC address. This has the disasterous result of a 2**28 = 268,435,200 ambiguity! Because al L3 addresses map into the same L2 multicast address, constraint of multicast traffic at L2 is impossible on Token Ring networks. A migration from Token-Ring to Ethernet should be considered by network administrators contemplating any extensive use of IP multicast.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

Layer 2 Multicast Addressing Token-Ring MAC Addresses


Token Ring Interfaces may be configured to use either the Functional Address or the all ones Broadcast Address
interface token-ring 0 ip pim sparse ip multicast useuse -functional

Use Functional Address 0xc000.0004.000

interface token-ring 0 ip pim sparse

Use Broadcast Address 0xffff.ffff.ffff (Default)

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

9 9

Default Configuration
The default Token Ring interface configuration is to use the broadcast address.

Recommended Configuration
If Functional Address support is available on IP multicast Token Ring end systems, it is recommended the Functional Address be used since this will not affect non-IP multicast users like the broadcast address will.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

IGMP
How hosts tell routers about group membership Routers solicit group membership from directly connected hosts RFC 1112 specifies first version of IGMP RFC 2236 specifies current version of IGMP IGMP v3 enhancements Supported on UNIX systems, PCs, and MACs

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

10 10

IGMP
The primary purpose of IGMP is to permit hosts to commincate their desire to receive multicast traffic to the IP Multicast router(s) on the local network. This, in turn, permits the IP Multicast router(s) to Join the specified multicast group and to begin forwarding the multicast traffic onto the network segment. The initial specification for IGMP (v1) was documented in RFC 1112, Host Extensions for IP Multicasting. Since that time, many problems and limitations with IGMPv1 have been discovered. This has lead to the development of the IGMPv2 specification which was ratified in November, 1997 as RFC 2236. Even before IGMPv2 had been ratified, work on the next generation of the IGMP protocol, IGMPv3, had already begun. However, the IGMPv3 specification is still in the working stage and has not been implemented by any v endors.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

10

IGMPv1

RFC 1112 Host extensions for IP Multicasting


Membership Queries
Querier sends IGMP query messages to 224.0.0.1 with ttl = 1 One router on LAN is designated/elected to send queries Query interval 60120 seconds

Membership Reports
IGMP report sent by one host suppresses sending by others Restrict to one report per group per LAN Unsolicited reports sent by host, when it first joins the group
Module2. ppt 8/9/2001 4:20 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

11 11

IGMP Membership Queries


IGMPv1 Membership Queries are sent by the router to the All-Hosts (224.0.0.1) multicast address to solicit what multicast groups have active receivers on the local network.

IGMP Membership Reports


IGMPv1 Membership Reports are sent by hosts wishing to receive traffic for a specific multicast group. Membership Reports are sent (with a TTL of 1) to the multicast address of the group for which the hosts wishes to receive traffic. Hosts either send reports asynchronously (when the wish to first join a group) or in response to Membership Queries. In the latter case, the response is used to maintain the group in an active state so that traffic for the group continues to be forwarded to the network segment.

Report Suppression
Report suppression is used among group members so that all members do not have to respond to a query. This saves CPU and bandwidth on all systems. The rule in multicast membership is that as long as one member is present, the group must be forwarded onto that segment. Therefore, only one member present is required to keep interest in a given group so report suppression is efficient.

TTL
Since Membership Query and Report packets only have local significance, the TTL of these packets are always set to 1. This is also so they will not be accidentally forwarded off of the local subnet and cause confusion on other subnets.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

11

IGMPv1Packet Format
4 Ver 7 Type Unused 15 23 Checksum 31

Group Address

Ver: Code Version = 1 Type: 1 = Host Membership Query 2 = Host Membership Report Group Address: Multicast Group Address

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

12 12

Version
is the IGMP version and should be 0x1 in IGMPv1. This field has been merged with the Type field in IGMPv2 and eliminated.

Type
is the IGMP message type. 0x1 = Host Membership Query 0x2 = Host Membership Report This field has been expanded into an 8 bit field in IGMPv2 .

Group
is the Multicast Group address being specified for reports.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

12

IGMPv1Joining a Group
H1 H2 224.1.1.1 H3

Report

IGMPv1

Joining member sends report to 224.1.1.1 immediately upon joining


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

13 13

Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in an unsolicited report indicating their interest. This reduces join latency for the end system joining if no other members are present.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

13

IGMPv1General Queries
H1 H2 H3

General Query to 224.0.0.1 IGMPv1 Multicast Router

Periodically sends General Queries to 224.0.0.1 to determine memberships


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

14 14

General Queries
General Queries go to the All-Hosts (224.0.0.1) multicast address. One member from each group on the segment will respond with a report. General Queries are sent out periodically based on the setting of the ip igmp query-interval command. (The default setting is 60 seconds.)

IGMP Querier
There is no formal IGMP Query Router election process within IGMPv1 itself. Instead, the election process is left up to the multicast routing protocol and different protocols used different mechanisms. This often results in multiple queriers on a single multi-access network.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

14

IGMPv1Maintaining a Group
224.1.1.1 H1 224.1.1.1 H2 224.1.1.1 H3

X
Suppressed #3 Report #2

X
Suppressed #3 Query to 224.0.0.1 IGMPv1 #1

#1 #2 #3
Module2. ppt

Router sends periodic queries One member per group per subnet reports Other members suppress reports
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

15 15

Query-Response Process
The router multicasts periodic IGMPv1 Membership Queries to the All-Hosts (224.0.0.1) group address. Only one member per group responds with a report to a query. This is to save bandwidth on the subnet network and processing by the hosts. This is process is called Response Suppression. (See below.)

Response Suppression Mechanism


The Report Suppression mechanism is accomplished as follows: When a host receives the Query, it starts a count-down timer for each multicast group of which it is a member. The count-down timers are each initialized to a random count within a given time range. (In IGMPv1 this was a fixed range of 10 seconds. Therefore the count-down timers were randomly set to some value between 0 and 10 seconds.) When a count-down timer reaches zero, the host sends a Membership Report for the group associated with the count-down timer to notify the router that the group is still active. However, if a host receives a Membership Report before its associated count-down timer reaches zero, it cancels the count-down timer associated with the multicast group, thereby suppressing its own report. In the example shown in the slide, H2s time expired first so it responded with its Membership Report. H1 and H3 cancelled their timers associated with the group; thereby suppressing their reports.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

15

IGMPv1Leaving a Group
H1 H2 H3

Query to 224.0.0.1 IGMPv1

Module2. ppt

Router sends periodic queries Hosts silently leave group Router continues sending periodic queries No Reports for group received by router Group times out
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

16 16

IGMPv1 Leaves
There was no special Leave mechanism defined in Version 1 of IGMP. Instead, IGMPv1 hosts leave a group "passively" or "quietly" at any time without any notification to the router. This is not a problem if there are multiple member present because the multicast flow still must be delivered to the segment. However, when the member leaving is the last member, there will be a period when the router continues to forward the multicast traffic onto the segment needlessly since there are no members left. It was up to the IGMP Query router to timeout the Group after several Query Intervals pass without a response for a Group. This is inefficient - especially if the number of groups and/or the traffic in these groups is high.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

16

IGMPv2

RFC 2236
Group-specific query
Router sends Group-specific queries to make sure there are no members present before stopping to forward data for the group for that subnet

Leave Group message


Host sends leave message if it leaves the group and is the last member (reduces leave latency in comparison to v1)
17 17

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

IGMPv2
As a result of some of the limitations discovered in IGMPv1, work was begun on IGMPv2 in an attempt to remove these limitations. Most of the changes between IGMPv1 and IGMPv2 are primarily to address the issues of Leave and Join latencies as well as address ambiguities in the original protocol specification. (IGMPv2 is almost to standard status.) The following sections define some of the more significant changes.

Group Specific Queries


A Group Specific query was added in v2 to allow the router to only query membership in a single group instead of all groups. This is an optimized way to quickly find out if any members are left in a group without asking all groups for a report. The difference between the Group Specific query and the General Query is that a General Query is multicast to the All-Hosts (224.0.0.1) address while a Group Specific query for Group G, is multicast to the Group G multicast address.

Leave Group message


A Leave Group message was also added in IGMPv2. This allows end systems to tell the router they are leaving the group which reduces the leave latency for the group on the segment when the member leaving is the last member of the group. The standard is loosely written on when leave group messages should and must be sent. This is an important consideration when discussing CGMP.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

17

IGMPv2 (cont.)

Querier election mechanism


On multi-access networks, an IGMP Querier router is elected based on lowest IP address. Only the Querier router sends Queries.

Query-Interval Response Time


General Queries specify Max. Response Time which inform hosts of the maximum time within which a host must respond to General Query. (Improves burstiness of the responses.)

Backward compatible with IGMPv1


Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

18 18

Querier Election
IGMP itself now has a Querier election mechanism unlike v1. The lowest unicast IP address of the IGMP-speaking routers will be elected as the Querier. All IGMP speaker come up thinking they will be the querier but must immediately relinquish that role if a lower IP address query is heard on the same segment.

Query-Interval Response Time


The Query-Interval Response time has also been added to control the burstiness of reports. This value is indicated in queries to convey to the membership how much time they have to respond to a query with a report.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

18

IGMPv2Packet Format
7 Type Max. Resp. Time Group Address 15 Checksum 31

Type: 0x11 = Membership Query 0x12 = Version 1 Membership Report 0x16 = Version 2 Membership Report 0x17 = Leave Group Max. Resp. Time max. time before sending a responding report in 1/10 secs. (Default = 10 secs) Group Address: Multicast Group Address (0.0.0.0 for General Queries)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

19 19

Type
In IGMPv2, the old 4 bit Version field was merged with the old 4 bit Type field to create a new 8 bit Type field. By assigning IGMPv2 type codes 0x11 and 0x12 as the Membership Query (V1 & V2) and the V1 Membership Report respectively, backwards compatibility of IGMP v1 and v2 packet formats was maintained.

Max. Response Time


This new field allows the querying router to specify exactly what the Query Interval Response Time is for this Query. The value (in 1/10 seconds) is used by the IGMPv2 hosts as the upper bound when randomly choosing the value of their response timers. This helps to control the burstiness of the responses during the Query-Response interval.

Group Address
This field is identical to the IGMPv1 version of this field with the exception that it is set to 0.0.0.0 for General Queries.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

19

IGMPv2Joining a Group
1.1.1.10 H1 1.1.1.11 224.1.1.1 H2 1.1.1.12 H3

Report 1.1.1.1 rtr-a

Joining member sends report to 224.1.1.1 immediately upon joining (same as IGMPv1)
20 20

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in an unsolicited report indicating their interest. This reduces join latency for the end system joining if no other members are present.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

20

IGMPv2Joining a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3

1.1.1.1 rtr-a IGMP State in rtr-a

rtr-a>show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime 224.1.1.1 Ethernet0 6d17h

Expires 00:02:31

Last Reporter 1.1.1.11

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

21 21

IGMP State in rtr-a


Group 224.1.1.1 is active on Ethernet 0 and Has been active on this interface for 6 days and 17 hours. It expires (and will be deleted) in 2 minutes and 31 seconds if an IGMP Host Membership report for this group is not heard in that time. The last Host to report membership was 1.1.1.11 (H2).

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

21

IGMPv2Querier Election
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3

Query IGMP Non-Querier

1.1.1.2 IGMPv2 rtr-b

1.1.1.1

Query IGMP Querier

rtr-a

Intially all routers send out a Query Router w/lowest IP address elected querier Other routers become Non-Queriers
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

22 22

Querier Election
In IGMPv1 there was no formal IGMP querying router election process in within IGMPv1 itself - it was left up to the multicast routing protocol and different protocols used different mechanisms. This would often result in multiple queriers on a single multiaccess network. With the definition of IGMPv2 a formal querying router election process was specified within the IGMPv2 protocol itself. In IGMPv2 each router on a multiaccess network will initially assume it is the querier and begin sending queries. Each router will see the queries from the other IGMPv2 routers and will examine the IP address of these queries. All IGMPv2 routers will then defer to the router with the lowest IP address. In other words, the IGMPv2 router with the lowest IP address will become the querying router. Finally, if the currently elected Query Router fails to issue a query within a specified time limit, a timer in the other IGMPv2 routers will time-out and cause them to re-initiate the Query Election process.

Group Specific Queries


IGMPv2 also added the concept of Group Specific Queries. This is accomplished by sending the IGMPv2 Membership Query to the Groups multicast address as opposed to sending to the All Hosts (224.0.0.1) multicast address as is done for IGMPv2 General Queries.

Query Interval
Membership queries are sent every 60 seconds (default).

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

22

IGMPv2Querier Election
Determining which router is the IGMP Querier
rtr-a>show rtr-a>show ip ip igmp igmp interface interface e0 e0 Ethernet0 Ethernet0 is is up, up, line line protocol protocol is is up up Internet address is 1.1.1.1, Internet address is 1.1.1.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current Current IGMP IGMP version version is is 22 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 60 60 seconds seconds IGMP IGMP querier querier timeout timeout is is 120 120 seconds seconds IGMP max query response time IGMP max query response time is is 10 10 seconds seconds Inbound IGMP access group is Inbound IGMP access group is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 1.1.1.1 1.1.1.1 (this (this system) system) IGMP IGMP querying querying router router is is 1.1.1.1 1.1.1.1 (this (this system) system) Multicast groups joined: 224.0.1.40 224.2.127.254 Multicast groups joined: 224.0.1.40 224.2.127.254

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

23 23

Verifying the IGMPv2 Querier


Use the show ip igmp interface command to determine which router is the IGMPv2 Querier on the multiaccess network. Note that the Designated Router is a different function and is listed separately in the display above.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

23

IGMPv2Maintaining a Group
1.1.1.10 224.1.1.1 1.1.1.11 224.1.1.1 H2 224.1.1.1 1.1.1.12 H1 H3

X
Suppressed 1.1.1.1

Suppressed

Report

Query

IGMPv2

Router sends periodic queries One member per group per subnet reports Other members suppress reports
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

24 24

Query-Response Process
The router multicasts periodic IGMPv1 Membership Queries to the All-Hosts (224.0.0.1) group address. Only one member per group responds with a report to a query. This is to save bandwidth on the subnet network and processing by the hosts. This is process is called Response Suppression. (See section below.)

Response Suppression Mechanism


The Report Suppression mechanism is accomplished as follows: When a host receives the Query, it starts a count-down timer for each multicast group of which it is a member. The count-down timers are each initialized to a random count within a given time range. (In IGMPv1 this was a fixed range of 10 seconds. Therefore the count-down timers were randomly set to some value between 0 and 10 seconds.) When a count-down timer reaches zero, the host sends a Membership Report for the group associated with the count-down timer to notify the router that the group is still active. However, if a host receives a Membership Report before its associated count-down timer reaches zero, it cancels the count-down timer associated with the multicast group, thereby suppressing its own report. In the example shown in the slide, H2s time expired first so it responded with its Membership Report. H1 and H3 cancelled their timers associated with the group; thereby suppressing their reports.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

24

IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3

1.1.1.1 rtr-a

IGMP State in rtr-a before Leave


rtr-a>sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime 224.1.1.1 Ethernet0 6d17h Expires 00:02:31 Last Reporter 1.1.1.11

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

25 25

IGMPv2 Leaves
In the above example, notice that the router is aware that there one or more members of group 224.1.1.1 active on Ethernet0 and that Host 2 responded with a Group Membership Report for this group during the last General Query interval. (Indicated by the IP address of Host 2 in the Last Reporter field.)

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

25

IGMPv2Leaving a Group
1.1.1.10 H1 224.1.1.1 Leave to #1 224.0.0.2 1.1.1.11 H2 224.1.1.1 Report to #3 224.1.1.1 1.1.1.1 rtr-a Group Specific Query to 224.1.1.1 #2 1.1.1.12 H3


Module2. ppt

H2 leaves group; sends Leave message Router sends Group specific query A remaining member host sends report Group remains active
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

26 26

IGMPv2 Leaves
In IGMPv1, hosts would leave passively - i.e.. they do not explicitly say they are leaving - they just stop reporting. However, IGMPv2 has explicit Leave Group messages. When the IGMPv2 Query router receives a Leave Message, it responds by sending a Group Specific Query for the associated group to see if there are still other hosts wishing to receive traffic for the group. This process helps to reduce overall Leave Latency. When CGMP is in use, the IGMPv2 Leave Message mechanism also helps the router to better manage the CGMP state in the switch. This also improves the leave latency for the specific host at layer 2. (Note: Due to the wording of the current IGMPv2 draft specification, hosts may chose to NOT send Leave messages if they are not the last host to leave the group. This can adversely affect CGMP performance.)

Example :
H2 and H3 are members of group 224.1.1.1 #1 - H2 leaves #2 - Router sends group specific query to see if any other group members are present. #3 - H3 hasnt left yet so it responds with a Report message. Router keeps sending multicast for 224.1.1.1 since there is >= 1 member present

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

26

IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3

1.1.1.1 rtr-a

IGMP State in rtr-a after H2 Leaves


rtr-a> rtr-a>sh sh ip ip igmp igmp group group IGMP IGMP Connected Connected Group Group Membership Membership Group Interface Uptime Group Address Address Interface Uptime 224.1.1.1 Ethernet0 6d17h 224.1.1.1 Ethernet0 6d17h Expires Last Expires Last Reporter Reporter 00:01:47 00:01:47 1.1.1.12 1.1.1.12

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

27 27

IGMPv2 Leaves
At this point, the group is still active. However, the router shows that Host 3 is the last host to send an IGMP Group Membership Report.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

27

IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 224.1.1.1 Leave to #1 224.0.0.2 1.1.1.1 rtr-a Group Specific Query to 224.1.1.1 #2 1.1.1.12 H3

Last host leaves group; sends Leave message Router sends Group specific query No report is received Group times out
1998 2001, Cisco Systems, Inc. All rights reserved.

Module2. ppt

8/9/2001 4:20 PM

28 28

IGMPv2 Leaves Example (continued):


H3 is the only remaining member of group 224.1.1.1 #1 - H3 leaves #2 - Router sends group specific query to see if any other group members are present. H3 was the last remaining member of the group so no IGMP Membership Report for group 224.1.1.1 is received and the group times out. (This typically takes from 1-3 seconds from the time that the Leave message is sent until the Group Specific Query times out and traffic stops flowing.)

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

28

IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3

1.1.1.1 rtr-a

IGMP State in rtr-a after H3 Leaves


rtr-a> rtr-a>show show ip ip igmp igmp group group IGMP IGMP Connected Connected Group Group Membership Membership Group Interface Uptime Group Address Address Interface Uptime Expires Expires Last Last Reporter Reporter

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

29 29

IGMPv2 Leaves
At this point, all hosts have left the 224.1.1.1 group on Ethernet0. This is indicated by rtr-a above.in the output of the show ip igmp group command.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

29

IGMPv2Response Tuning
Query Query

Query Resp. Interval Query Interval

Query Response Interval

Host Membership Reports (assuming 18 active Groups)

Report suppression mechanism tends to spread Reports out over the entire Query Response Interval
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

30 30

IGMPv2 Query-Response Tuning


Because random report timers are set on all hosts and report suppression is in effect - the reports are randomly distributed over the query response time interval instead of coming all at once. The query response interval is specified by the querying router as a guide for the end systems to set an upper bound on the random timer they will set for a report.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

30

IGMPv2Response Tuning
Query Query Query

Query Resp. Interval Query Interval

Query Resp. Interval Query Interval

Query Resp. Interval

Query

Query

Query

Query Resp. Interval Query Interval

Query Resp. Interval Query Interval

Query Resp. Interval

Increasing the Query Response Interval will spread out Reports; decreasing Burstiness.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

31 31

IGMPv2 Query Response Tuning (cont.)


The advantage of increasing the Query Interval and Query Response Interval is less overhead and bandwidth on the segment and less work for the routers and end systems to maintain the groups. The disadvantage for setting these intervals longer is the detection of router failures in redundant multicast router environments. This is a common tradeoff in most routing protocols. Short "keepalive" intervals mean more overhead and work but allow for faster convergence in failure scenarios.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

31

IGMPv2Response Tuning

interface Ethernet 0 ip pim sparse ip igmp queryquery -max max-response response-time 20

Tuning the Query Response Interval (Default = 10 secs)

interface Ethernet 0 ip pim sparse ip igmp queryquery -interval 120

Tuning the Query Interval (Default = 60 secs)

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

32 32

Query Response Tuning (cont.)


Use default settings when possible. Tune with care!

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

32

IGMPv2Response Tuning
Verifying IGMPv2 Response Tuning Values
jabber>show jabber>show ip ip igmp igmp interface interface e0 e0 Ethernet0 Ethernet0 is is up, up, line line protocol protocol is is up up Internet Internet address address is is 10.1.3.1, 10.1.3.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current Current IGMP IGMP version version is is 22 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 120 120 seconds seconds IGMP IGMP querier querier timeout timeout is is 240 240 seconds seconds IGMP max query response time IGMP max query response time is is 20 20 seconds seconds Inbound IGMP access group is Inbound IGMP access group is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 10.1.3.1 10.1.3.1 (this (this system) system) IGMP IGMP querying querying router router is is 10.1.3.1 10.1.3.1 (this (this system) system) Multicast groups joined: 224.0.1.40 224.2.127.254 Multicast groups joined: 224.0.1.40 224.2.127.254

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

33 33

Checking IGMP Response Tuning


Use the show ip igmp interface command to verify that the values are correct when you perform IGMP Response Tuning. In the above example, the Query Interval has been set to 120 seconds while the Max. Query Response Time is set to 20 seconds.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

33

IGMP v1-v2 Interoperability


IGMPv1 H1 IGMPv2 IGMPv1 Report #2 1.1.1.1 IGMPv1 Host H2: MUST always send IGMPv1 Reports MAY suppress IGMPv2 Leaves IGMPv1 #1 Query H2 IGMPv1 H3

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

34 34

IGMP v1-v2 Interoperability


IGMPv1 routers will not recognize IGMPv2 Membership Reports. Therefore, when IGMPv2 hosts are present on the same network as an IGMPv1 router (which is serving as the query router), the IGMPv2 capable hosts MUST send IGMPv1 Membership Reports so the IGMPv1 router will recognize them. In addition, if the router is running IGMPv1, it makes no sense for hosts to send Leave Messages. However, it will not hurt if they do.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

34

IGMP v1-v2 Interoperability


IGMPv2 H1 IGMPv1 224.1.1.1 Report 1.1.1.1 IGMPv2 Router A: MUST set a timer noting IGMPv1 member present for Group 224.1.1.1 MUST Ignore any v2 Leaves for Group 224.1.1.1 (until timer expires)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

H2

IGMPv2

H3

Router A

8/9/2001 4:20 PM

35 35

IGMP v1-v2 Interoperability (cont.)


If the query router is running IGMPv2, it must be able to recognize when v1 hosts are present since v1 hosts do not have advanced v2 query response interval awareness. Furthermore, in this situation an IGMPv2 must ignore any IGMPv2 Leave Messages since the v1 hosts present will not be able to recognize nor respond to IGMPv2 Group Specific queries. If the router were to process the Leave Message, send out an IGMPv2 Group Specific query and the only remaining host in the group was an IGMPv1 host, the group would be pruned when it should not have been.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

35

IGMP v1-v2 Interoperability


H1 H2 H3

1.1.1.1 IGMPv2 Router A Router A:

1.1.1.2 IGMPv1 Router B

Must be manually configured to use IGMPv1 on this interface.


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

36 36

IGMP v1-v2 Interoperability (cont.)


All routers on a network segment must run the same version of IGMP!!!! By default, IOS will run IGMPv2. If there are other IGMPv1 routers on the network segment, the Cisco router MUST be manually configured to run IGMPv1. The IOS configuration command used to manually configure the IGMP version on an interface is: ip igmp version 1|2 Note that in IOS versions prior to 11.1, the router would automatically attempt to ascertain the proper version of IGMP to run on an interface. Unfortunately, there are many corner cases which make this problematic and prone to error. Therefore, as of IOS version 11.1, it is necessary to perform this task manually with the above command.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

36

IGMP v1-v2 Interoperability


Determining which IGMP version is running on an interface
rtr-a> show rtr-a> show ip ip igmp igmp interface interface e0 e0 Ethernet0 Ethernet0 is is up, up, line line protocol protocol is is up up Internet Internet address address is is 1.1.1.1, 1.1.1.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current IGMP version is 2 Current IGMP version is 2 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 60 60 seconds seconds IGMP IGMP querier querier timeout timeout is is 120 120 seconds seconds IGMP max query response time IGMP max query response time is is 10 10 seconds seconds Inbound IGMP access group is Inbound IGMP access group is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 1.1.1.1 1.1.1.1 (this (this system) system) IGMP IGMP querying querying router router is is 1.1.1.1 1.1.1.1 (this (this system) system) Multicast groups joined: 224.0.1.40 224.2.127.254 Multicast groups joined: 224.0.1.40 224.2.127.254

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

37 37

Verifying the IGMP Version on an Interface


Use the show ip igmp interface command to determine which version of IGMP is currently active on an interface. This is indicated by the line in the above example that says Current IGMP version is 2

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

37

IGMPv3
draft-ietf-idmr-igmp-v3-??.txt
In EFT

Adds Include/Exclude Source Lists


Enables hosts to listen only to a specified subset of the hosts sending to the group Requires new IPMulticastListen API
New IGMPv3 stack required in the O/S.

Apps must be rewritten to use IGMPv3 Include/Exclude features


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

38 38

IGMPv3
The IDMR is completing work on IGMPv3. The key change in IGMPv3 is the addition of Group records each containing a list of sources to Include or Exclude. This permits a host to signal which set of hosts that they wish to receive group traffic. IGMPv3 requires that the IPMulticastListen API be changed to accommodate the Include/Exclude filter list. This means that the IGMP stack in the OS will have to be updated to support IGMPv3. In order to take advantage of the benefits of IGMPv3, applications must be (re)written to support the new API.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

38

IGMPv3
New Membership Report address
224.0.0.22 (IGMPv3 Routers)
All IGMPv3 Hosts send reports to this address
Instead of the target group address as in IGMPv1/v2

All IGMPv3 Routers listen to this address Hosts do not listen or respond to this address

No Report Suppression
All Hosts on wire respond to Queries Response Interval may be tuned over broad range
Useful when large numbers of hosts reside on subnet
Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

39 39

IGMPv3
IGMPv3 is assigned its own All IGMPv3 Routers link-local multicast group address, 224.0.0.22. IGMPv3 hosts no longer send their reports to the target multicast group address. Instead, they send their IGMPv3 Membership Reports to the All IGMPv3 Routers multicast address. Routers listen to the 224.0.0.22 address in order to receive and maintain IGMP membership state for every member on the subnet! This is a radical change over the behavior in IGMPv1/v2 where the routers only maintained group state on a subnet basis. Hosts do not listen to 224.0.0.22 and therefore do not hear other hosts IGMPv3 membership reports. IGMPv3 drops the Report Suppression mechanism that was used in IGMPv1/v2. All IGMPv3 hosts on the wire respond to Queries by sending and IGMPv3 membership reports containing their total IGMP state for all groups in the report. In order to prevent huge bursts of IGMPv3 Reports, the Response Interval may now be tuned over a much greater range than before. This permits the network engineer to adjust the burstiness of IGMPv3 Reports when there is a large number of hosts on the subnet.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

39

IGMPv3 Query Packet Format


Type = 0x11 IGMP Query Max. Resp. Time Max. time to send a response if < 128, Time in 1/10 secs if > 128, FP value (12.8 - 3174.4 secs ) Group Address: Multicast Group Address (0.0.0.0 for General Queries) S Flag Suppresses processing by routers QRV (Querier Robustness Value) Affects timers and # of retries QQIC (Queriers Query Interval) Same format as Max. Resp. Time Number of Sources (N) (Non-zero for Group-and-Source Query) Source Address Address of Source
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

7 Type = 0x11

15 Max. Resp. Code Group Address

31 Checksum

S QRV

QQIC

Number of Sources (N)

Source Address [1] Source Address [2] . . . Source Address [N]

8/9/2001 4:20 PM

40 40

Type
The same IGMPv2 type code 0x11 is used as the IGMPv3 Membership Query Type code.

Max. Response Time (1/10 seconds)


This field has been reformatted to permit longer times to be expressed. If the value is < 128, the the time is absolute (.1- 12.8 seconds). If the value is > 128, it is interpreted as a floating-point number as follows:
+-+-+-+-+-+-+-+-+ |1| exp | mant | value = (mant|0x10)<<(exp+3) +-+-+-+-+-+-+-+-+

Group Address
This field is identical to the IGMPv2 version of this field. It is set to 0.0.0.0 for General Queries.

S Flag
Indicates that the routers that receive this message should not process it.

QRV (Querier Robustness Value)


This value causes all hosts to adjust their Robustness Values which in turn affect various timers and retry counts. Increasing this value provides more protocol robustness at the expense of latency.

QQIC (Querier Query Interval)


This field indicates the Query Interval in use by the Querying router. Its format is the same as the Max. Response Time field.

Number of Sources
The number of Source Addresses in the Group-and-Source-Specific Query.
Copyright ? ?1998-2001 Cisco Systems, Inc.
Module2.ppt

40

IGMPv3 Report Packet Format


7 Type = 0x22 15 Reserved Checksum # of Group Records (M) 31 7 15 # of Sources (N) 31 Record Type Aux Data Len

Reserved

Multicast Group Address Group Record [1] Source Address [1] Source Address [2] . . . Source Address [N] Auxilliary Data Group Record [M]

Group Record [2] . . .

# of Group Records (M) Number of Group Records in Report Group Records 1 - M Group address plus list of zero or more sources to Include/Exclude (See Group Record format)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Record Type Include, Exclude, Chg-to-Include, Chg-to-Exclude, Add, Remove # of Sources (N) Number of Sources in Record Source Address 1- N Address of Source
8/9/2001 4:20 PM

41 41

# of Group Records
Indicates the number of Group records that are contained in the Membership Report. IGMPv3 Membership Reports can contain IGMP state on a number of Groups and Sources within the group. The source information specifies which Sources to Include or Exclude.

Aux. Data Length (Group Records)


Indicates the size of the Auxilliary Data area.

Multicast Address (Group Records)


The multicast group address of the joined Group.

# of Sources (Group Records)


Indicates the number of Sources in the list.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

41

IGMPv3 Example
Source = 1.1.1.1 Group = 224.1.1.1 R1 R2 Source = 2.2.2.2 Group = 224.1.1.1

H1 wants to receive only S = 1.1.1.1 and no other. With IGMP, specific sources can be joined. S = 1.1.1.1 in this case R3 IGMPv3: Join 224.1.1.1 Include: 1.1.1.1 H1 - Member of 224.1.1.1

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

42 42

IGMPv3 Example
In this example, host H1 wishes to join group 224.1.1.1 but only wishes to receive traffic from Source 1.1.1.1. The IGMPv3 host can signal the designated router, R3, that it is only interested in multicast traffic from Source 1.1.1.1 for Group 224.1.1.1. Router R3 could then potentially prune the unwanted source, 2.2.2.2,.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

42

IGMPv3Joining a Group
1.1.1.10 H1
v3 Report (224.0.0.22)

1.1.1.11 H2
Group: 224.1.1.1 Exclude: <empty>

1.1.1.12 H3

1.1.1.1 rtr-a

Joining member sends IGMPv3 Report to 224.0.0.22 immediately upon joining


43 43

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in an unsolicited IGMPv3 Membership Report indicating their interest. This reduces join latency for the end system joining if no other members are present. In the example above, Host 2 is joining multicast group 224.1.1.1 and is willing to receive any and all sources in this group.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

43

IGMPv3Joining specific Source(s)


1.1.1.10 H1
v3 Report (224.0.0.22)

1.1.1.11 H2
Group: 224.1.1.1 Include: 10.0.0.1

1.1.1.12 H3

1.1.1.1 rtr-a

IGMPv3 Report contains desired source(s) in the Include list. Only Included source(s) are joined.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

44 44

Joining only specific Source(s)


Hosts may signal the router that it wishes to receive only a specific set of sources sending to the group. This is done by using an Include list in the Group record of the Report. When an Include list is in use, only the specific sources listed in the Include list are joined. In the example above, Host 2 is joining multicast group 224.1.1.1 and only wants to receive source 10.0.0.1 sending to the group.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

44

IGMPv3Excluding specific Source(s)


1.1.1.10 H1
v3 Report (224.0.0.22)

1.1.1.11 H2
Group: 224.1.1.1 Exclude: 7.7.7.7

1.1.1.12 H3

1.1.1.1 rtr-a

IGMPv3 Report contains undesired source(s) in the Exclude list. All sources except Excluded source(s) are joined.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

45 45

Joining only specific Source(s)


Hosts may signal the router that it wishes to receive all sources sending to the group except a specific set of undesired sources. This is done by using an Exclude list in the Group record of the Report. When an Exclude list is in use, all sources in the group are joined except the sources listed in the Exclude list. In the example above, Host 2 is joining multicast group 224.1.1.1 and wish to receive multicast traffic from any source in the group except source 7.7.7.7.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

45

IGMPv3Maintaining State
1.1.1.10 H1
v3 Report (224.0.0.22) v3 Report (224.0.0.22)

1.1.1.11 H2

1.1.1.12 H3
v3 Report (224.0.0.22)

1.1.1.1

Query

Router sends periodic queries All IGMPv3 members respond


Reports contain multiple Group state records
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

46 46

Query-Response Process
The router multicasts periodic Membership Queries to the All-Hosts (224.0.0.1) group address. All hosts on the wire respond by sending back an IGMPv3 Membership Report that contains their complete IGMP Group state for the interface.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

46

L2 Multicast Frame Switching

Problem: Layer 2 Flooding of Multicast Frames


Typical L2 switches treat multicast traffic as unknown or broadcast and must flood the frame to every port Static entries can sometimes be set to specify which ports should receive which group(s) of multicast traffic Dynamic configuration of these entries would cut down on user administration
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

PIM

Multicast M

8/9/2001 4:20 PM

47 47

L2 Multicast Switching
For most L2 Switches, Multicast traffic is normally treated like an unknown MAC address or Broadcast frame which causes the frame to be flooded out every port within a VLAN at rates of over 1 Mbps. This is fine for unknowns and broadcasts but as we have seen earlier, IP Multicast hosts may join and be interested in only specific multicast groups. Again, on most L2 Switches, all this traffic is forwarded out all ports resulting in wasted bandwidth on both the segments and on the end stations. One way around this on Catalyst Switches is using the Command Line Interface to program the switch manually to associate a multicast MAC address with say ports 5,6,7 so only ports 5,6,and 7 receive the multicast traffic destined for the multicast group. This works fine but again we know IP Multicast hosts dynamically join and leave groups using IGMP to signal to the Multicast Router. This static way of entering the multicast information is not very scaleable. Dynamic configuration of the Switches forwarding tables would be a better idea, and cut down on user administration.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

47

L2 Multicast Frame Switching

Solution 1: IGMP Snooping


Switches become IGMP aware IGMP packets intercepted by the NMP or by special hardware ASICs Switch must examine contents of IGMP messages to determine which ports want what traffic
IGMP membership reports IGMP leave messages PIM

Impact on switch:
Must process ALL Layer 2 multicast packets Admin. load increases with multicast traffic load Requires special hardware to maintain throughput

IGMP

IGMP
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

48 48

Solution 1: IGMP Snooping


As its name implies, switch become IGMP aware and listen in on the IGMP conversations between hosts and routers. This requires the processor in the switch to identify and intercept a copy of all IGMP packets flowing between router and hosts and vice versa. This includes: IGMP Membership Reports IGMP Leaves If care is not taken as to how IGMP Snooping is implemented, a switch may have to intercept ALL layer 2 multicast packets in order to identify IGMP packets. This can have a significant impact on the switchs performance. Proper designs require special hardware to avoid this problem. This can directly affect the overall cost of the switch.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

48

Typical L2 Switch Architecture


Router A 1 LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0000.6503.1d0e Port 5

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3 Host 4 (0000.6503.1d0e)


8/9/2001 4:20 PM

49 49

Typical Layer 2 Switch


Most Layer 2 switches consist of the following components: Switching Engine - Used to actually perform switching of packets from the input port to the output port(s) under the control of the Contents Addressable Memory (CAM) Table. If there is no entry in the CAM Table that matches the destination MAC address, the Switching Engine will flood the packet to all ports in an attempt to insure that the packet reaches the destination. CAM Table - The information in this table is used to control the operation of the Switching Engine. Each entry in this table contains a Layer 2 destination MAC address and output port(s) where packets addressed to this destination should be switched. CPU - The switchs main CPU populates the CAM Table with destination MAC addresses so that packets can be switched efficiently by the Switching Engine. The CPU learns the ports associated with a particular MAC address by watching arriving traffic sent by hosts. It then populates the CAM Table with this learned information. (Switches can typically also be instructed to populate the CAM Table with specific MAC address to port mapping information via configuration commands.) In the example shown above, the switch has learned the port (port 5) associated with Host 4s MAC address (0000.6503.1d0e). This information has been stored by the CPU in the CAM Table. Because of this CAM Table entry, packets arriving with Host 4s MAC address as the destination are being switched by the Switching Engine to port 5 as can be seen in the drawing above. In the next few pages, we will see how this simply Layer 2 architecture might be used to implement IGMP Snooping and its potential impact on the switch.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

49

Typical L2 Switch 1st Join


Router A 1 (IGMP Snooping Enabled) 0 IGMP Report 224.1.2.3

LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address Ports

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

50 50

IGMP Snooping in L2 Switches


In the above example, the CPU has been programmed to perform IGMP Snooping. This requires the CPU to listen to all IGMP traffic and then add an appropriate Layer 2 multicast MAC address to the CAM Table in order to constrain the IP Multicast traffic to only those ports that require the traffic. Initially, when the first host (Host 1) joins group 224.1.2.3, there is no entry in the CAM table associated with the Layer 2 MAC address equivalent to this group address. Therefore, the initial IGMP Group Membership Report sent by Host 1 is flooded to all ports including the switchs CPU and the Router. Overhearing this, the CPU populates the CAM table with an entry of 0x0100.5e01.0203 which is the L2 MAC address equivalent of IP multicast address 224.1.2.3. Additionally, this entry is populated with the port associated with Host 1 (port 2) as well as the Router and the CPU ports (ports 0 and 1). The CPU port must be included in order for the Switching Engine to continue to forward any further IGMP messages addressed to this group to the CPU for processing.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

50

Typical L2 Switch 1st Join


Router A 1 (IGMP Snooping Enabled) 0

LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2

Entry Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

51 51

IGMP Snooping in L2 Switches


In the above example, the CPU has been programmed to perform IGMP Snooping. This requires the CPU to listen to all IGMP traffic and then add an appropriate Layer 2 multicast MAC address to the CAM Table in order to constrain the IP Multicast traffic to only those ports that require the traffic. Initially, when the first host (Host 1) joins group 224.1.2.3, there is no entry in the CAM table associated with the Layer 2 MAC address equivalent to this group address. Therefore, the initial IGMP Group Membership Report sent by Host 1 is flooded to all ports including the switchs CPU and the Router. Overhearing this, the CPU populates the CAM table with an entry of 0x0100.5e01.0203 which is the L2 MAC address equivalent of IP multicast address 224.1.2.3. Additionally, this entry is populated with the port associated with Host 1 (port 2) as well as the Router and the CPU ports (ports 0 and 1). The CPU port must be included in order for the Switching Engine to continue to forward any further IGMP messages addressed to this group to the CPU for processing.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

51

Typical L2 Switch 2nd Join


Router A 1 (IGMP Snooping Enabled) 0 IGMP Report 224.1.2.3

LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

52 52

IGMP Snooping in L2 Switches


Now lets assume that a second host (Host 4) also joins the group by sending an IGMP Report to group 224.1.2.3. Because of the CAM Table entry for 0x0100.5e01.02.03, this IGMP Report is constrained to only Host 1, the router and the CPU. When the CPU receives the IGMP Report, it simply adds the port (port 5) on which Host 4 is connected to the CAM Table entry. This results in ports 0, 1, 2 and 5 being associated with the multicast MAC address 0x0100.5e01.02.03.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

52

Typical L2 Switch 2nd Join


Router A 1 (IGMP Snooping Enabled) 0

LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2,5

Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

53 53

IGMP Snooping in L2 Switches


Now lets assume that a second host (Host 4) also joins the group by sending an IGMP Report to group 224.1.2.3. Because of the CAM Table entry for 0x0100.5e01.02.03, this IGMP Report is constrained to only Host 1, the router and the CPU. When the CPU receives the IGMP Report, it simply adds the port (port 5) on which Host 4 is connected to the CAM Table entry. This results in ports 0, 1, 2 and 5 being associated with the multicast MAC address 0x0100.5e01.02.03.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

53

Typical L2 Switch Meltdown!


6Mbps !!! Choke, Gasp, Wheeze!!

Router A 1 (IGMP Snooping Enabled) 0

LAN Switch

CPU

Switching Engine
6Mbps MPEG Video

CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2,5

Host 1 Host 2 (MPEG Server)


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 3

Host 4
8/9/2001 4:20 PM

54 54

IGMP Snooping in L2 Switches


Let us now assume that Host 1 begins transmitting a 1.5Mbps MPEG video stream to multicast group 224.1.2.3. Because the destination MAC address of this stream maps to 0x0100.5e01.02.03, the Switching Engine dutifully switches this traffic to Host 4, the Router and the CPU! In most cases, the switchs CPU does not have sufficient horsepower to keep up with this high rate flow of multicast traffic and switch performance can suffer. In some cases, the switch can actually fail under such loads.

Summary
IGMP Snooping can be (and often is) implemented in low-end, Layer-2 only switches using techniques similar to the above. While this is fine for extremely low data-rate multicast flows or carefully orchestrated vendor demonstrations of their switchs IGMP Snooping feature, it is generally inadequate for real-world use.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

54

L3 Aware Switch
Router A 1 (IGMP Snooping Enabled) 0

LAN Switch

CPU

Switching Engine (w/L3 ASICs)

CAM Table
2
MAC Address 0100.5exx.xxxx L3 IGMP Ports 0

IGMP Processing Entry


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

55 55

IGMP Snooping in L3-aware Switches


In order to properly implement IGMP Snooping on a switch without suffering performance degradation, it is necessary to make the switch Layer 3 aware. This is typically accomplished adding Layer 3 ASICs to the Switching Engine in addition to extending the CAM Table so that entries may contain additional Layer 3 information that can be used to make switching decisions. (In case it is not obvious, this means the switch will cost more money.) In the above example, we have just such a Layer-3 aware switch that has been programmed to perform IGMP Snooping using some of the added Layer 3 capabilities in the switchs architecture. In order to accomplish this, the CPU populates the CAM Table with a special entry to capture any and all IGMP packets. There can be many ways to do this but in the example above, the CAM Table entry contains a wildcard MAC address that will match on any IP multicast address. Furthermore, the Layer 3 part of the packet must contain an IGMP protocol packet in order for the entry to match and cause the packet to be switched to the CPU

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

55

L3 Aware Switch 1st Join


Router A 1 (IGMP Snooping Enabled) 0

LAN Switch

CPU

Switching Engine (w/L3 ASICs)


IGMP Report 224.1.2.3

CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 L3 IGMP !IGMP Ports 0 1,2

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

56 56

IGMP Snooping in L3-aware Switches


Lets assume that the first host (Host 1) now joins group 224.1.2.3 and signals this by sending an IGMP Report. This report matches on the first entry in the CAM Table and is switched to the CPU. The CPU responds by forwarding the packet on to the Router (for normal IGMP processing) and then adds a second entry to the CAM table to switch 224.1.2.3 group traffic to Host 1 and the Router (ports 1 and 2). This second entry will match IFF: The packet is addressed to multicast MAC address 0x0100.5e01.0203 (the Layer 2 equivalent to group address 224.1.2.3) and The packet is not and IGMP packet.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

56

L3 Aware Switch 2nd Join


Router A 1 (IGMP Snooping Enabled) 0
IGMP Report 224.1.2.3

LAN Switch

CPU

Switching Engine (w/L3 ASICs)

CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

L3 IGMP !IGMP

Ports 0 1,2,5

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

57 57

IGMP Snooping in L3-aware Switches


Now lets assume that again Host 4 is the second host to join 224.1.2.3 and therefore sends an IGMP Report to 224.1.2.3. Once again, the IGMP Report matches on the first entry and is switched to the CPU. The CPU responds by forwarding a copy of the IGMP Report to the Router and by adding the port associated with Host 4 (port 5) to the port list in the second CAM Table entry.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

57

L3 Aware Switch
Ahhh, Thats more like it!

Router A

LAN Switch

1 (IGMP Snooping Enabled) 0

CPU

Switching Engine (w/L3 ASICs)


6Mbps MPEG Video

CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 L3 IGMP !IGMP Ports 0 1,2,5

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

58 58

IGMP Snooping in L3-aware Switches


In the final step of our example, Host 1 once again starts up the 1.5Mbps MPEG video stream to group 224.1.2.3. Packets in this stream will not match on the first CAM Table entry but instead will match on the second entry. Therefore, the video stream is switched to only Host 4 and the Router and the CPU is not burdened with this unwanted data stream.

Summary
In order to construct a switch that is capable of IGMP Snooping without suffering a performance hit, the switch must use special Layer 3 ASIC or some similar technique. This increases the overall cost of the switch.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

58

L2 Multicast Frame Switching

Solution 2: CGMPCisco Group Multicast Protocol


Runs on both the switches and the router Router sends CGMP multicast packets to the switches at a well known multicast MAC address:
0100.0cdd.dddd
PIM

CGMP packet contains :


Type fieldJoin or Leave MAC address of the IGMP client Multicast address of the group

CGMP Commands

IGMP

Switch uses CGMP packet info to add or remove an entry for a particular multicast MAC address
Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

59 59

Solution 2: CGMP
CGMP is based on a client server model where the router can be considered a CGMP server and the switch taking on the client role. There are software components running on both devices, with the router translating IGMP messages into CGMP commands which are then executed on the Catalyst 5000 NMP and used to program the EARLs forwarding tables with the correct Multicast entries. Since the hosts and routers use well-known IP Multicast Addresses, the EARL can be preprogrammed to direct IGMP Control packets both to the router and the NMP. We will see the NMPs use of these IGMP control packets in a later slide. The basis of CGMP is that the IP Multicast router sees all IGMP packets and therefore can inform the switch when specific hosts join or leave Multicast groups. The switch then uses this information to program its forwarding table. When the router sees an IGMP control packet it creates a CGMP packet that contains the request type (Join or Leave), the Layer 2 Multicast MAC Address, and the actual MAC address of the client. This packet is sent to a well known address which all CGMP switches listen on. It is then interpreted and the proper entries created in the switchs CAM Table to constrain the forwarding of multicast traffic for this group.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

59

CGMP Basics

IGMP Report
Dst MAC = 0100.5e01.0203 Src MAC = 0080.c7a2.1093 Dst IP = 224.1.2.3 Src IP = 192.1.1.1 IGMP Group = 224.1.2.3

CGMP Join
1/1 1/1
USA = 0080.c7a2.1093 GDA = 0100.5e01.0203

5/1

5/1

(a)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

(b)
8/9/2001 4:20 PM

60 60

CGMP Example
In this example - the client will asynchronously send an IGMP Membership Report when it wants to join the group. The Router converts this IGMP Membership Report into a CGMP Join containing: USA - Unicast Source Address GDA - Group Destination Address The CGMP Join is multicast to a well-known (non-IP) multicast MAC address which the switch listens on.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

60

CGMP Packet Format


3 Ver Type 7 15 Reserved GDA GDA USA USA 23 Count 31

Ver (4 bits): Type (4 bits): Count (1 byte): GDA (6 bytes): USA (6 bytes):

Only version 1 is currently recognized and supported 0 = Join, 1 = Leave Number of GDA/USA pairs in the packet Group Destination Address - IEEE MAC level canonical format Unicast Source Address - IEEE MAC-level canonical format

Reserved (2 bytes): Must be set to 0 and ignored

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

61 61

CGMP Packet Format


All CGMP packets encapsulated in SNAP frames using Ciscos ORG ID (0x00000c) with an Ethertype of 2001: Mac Header 802.2 Header: SNAP Header CGMP Header aa aa 03 00 00 0c 20 01

Most sniffers and software capture programs do not decode CGMP (have fun with the hex decodes)

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

61

CGMP 1st Join


Router A 1 Simple LAN Switch
IGMP Report 224.1.2.3

CPU

Switching Engine

CAM Table
2
MAC Address Ports

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7a2.1093
62 62

CGMP Implementation in L2 switches


Because the switch relies on the Router to assist in the process of constraining IP multicast traffic at Layer 2, it can be implemented very easily in low-end, Layer2 only switches. In the above CGMP example, the first host (Host 1) joins multicast group 224.1.2.3 by sending an IGMP Membership Report. Because there is no matching entry in the CAM Table, the IGMP Membership Report is flooded to all ports including the Router who processes the IGMP Report.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

62

CGMP 1st Join


Router A 1 Simple LAN Switch

CPU

Switching Engine
CGMP Join USA 0080.c7a2.1093 GDA 0100.5e01.0204

CAM Table
2
MAC Address Ports

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7a2.1093
63 63

CGMP Implementation in L2 switches


In addition to performing normal IGMP processing of the IGMP Membership Report, the Router also converts it into a CGMP Join message containing the MAC address of the host that sent the IGMP Report (Host 1) in the USA field and the Layer 2 MAC address equivalent of group 224.1.2.3 in the GDA field. This CGMP Join message is then multicast back to the switch. When the switch receives the CGMP Join, it uses the host address in the USA field to determine the port where the Host resides. This is done by scanning the CAM table for the hosts MAC address to obtain the associated port number. (This step is not shown in the example above.) The CPU then populates its CAM Table with an entry containing the multicast MAC address from the GDA field and the port number of the host that joined along with the port numbers of any routers connected to the switch. Note: The CPU has many ways to determine which ports have routers attached. These include listening for DVMRP Probes, PIM Hellos, and IGMP Queries.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

63

CGMP 1st Join


Router A 1 Simple LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2

Entry Added
Module2. ppt

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7a2.1093
64 64

1998 2001, Cisco Systems, Inc. All rights reserved.

CGMP Implementation in L2 switches


In addition to performing normal IGMP processing of the IGMP Membership Report, the Router also converts it into a CGMP Join message containing the MAC address of the host that sent the IGMP Report (Host 1) in the USA field and the Layer 2 MAC address equivalent of group 224.1.2.3 in the GDA field. This CGMP Join message is then multicast back to the switch. When the switch receives the CGMP Join, it uses the host address in the USA field to determine the port where the Host resides. This is done by scanning the CAM table for the hosts MAC address to obtain the associated port number. (This step is not shown in the example above.) The CPU then populates its CAM Table with an entry containing the multicast MAC address from the GDA field and the port number of the host that joined along with the port numbers of any routers connected to the switch. Note: The CPU has many ways to determine which ports have routers attached. These include listening for DVMRP Probes, PIM Hellos, and IGMP Queries.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

64

CGMP 2nd Join


Router A 1 Simple LAN Switch
IGMP Report 224.1.2.3

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7b3.2174
65 65

CGMP Implementation in L2 switches


Next, lets assume that (once again) Host 4 is the second host to join group 224.1.2.3 and signals this by sending an IGMP Report to 224.1.2.3. Because the IGMP Report is sent to group 224.1.2.3, the MAC destination address is 0x0100.5e01.0203 which matches on the first entry in the CAM Table shown above. This results in the IGMP Report being sent to Host 1 and the Router.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

65

CGMP 2nd Join


Router A 1 Simple LAN Switch

CPU

Switching Engine
CGMP Join USA 0080.c7b3.2174 GDA 0100.5e01.0204

CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2

Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7b3.2174
66 66

CGMP Implementation in L2 switches


In addition to performing normal IGMP processing of the IGMP Membership Report, the Router again converts it to a CGMP Join message containing the MAC address of Host 4 in the USA field and the Layer 2 MAC address equivalent of group 224.1.2.3 in the GDA field. The resulting CGMP Join message is then multicast back to the switch. When the switch receives this CGMP Join, it again uses the host address in the USA field to determine the port where the Host resides. (In this case, port 5.) The CPU then adds port 5 to the port list in the existing CAM Table entry associated with the multicast MAC address from the GDA field.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

66

CGMP 2nd Join


Router A 1 Simple LAN Switch

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2,5

Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 1

Host 2

Host 3

Host 4
8/9/2001 4:20 PM

0080.c7b3.2174
67 67

CGMP Implementation in L2 switches


In addition to performing normal IGMP processing of the IGMP Membership Report, the Router again converts it to a CGMP Join message containing the MAC address of Host 4 in the USA field and the Layer 2 MAC address equivalent of group 224.1.2.3 in the GDA field. The resulting CGMP Join message is then multicast back to the switch. When the switch receives this CGMP Join, it again uses the host address in the USA field to determine the port where the Host resides. (In this case, port 5.) The CPU then adds port 5 to the port list in the existing CAM Table entry associated with the multicast MAC address from the GDA field.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

67

CGMP No Load on Switch


Router A 1 Simple LAN Switch

CPU

Switching Engine
6Mbps MPEG Video

CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2,5

Host 1 Host 2 (MPEG Server)


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 3

Host 4
8/9/2001 4:20 PM

68 68

CGMP Implementation in L2 switches


In our final drawing of the example, Host 1 again begins sourcing its 1.5Mbps MPEG video stream to group 224.1.2.3. When this stream hits the switch, it matches on the first entry in the CAM Table and is switched to Host 4 and the Router. Note that because the CPUs port is not included in this entry, the high-rate video stream is not being sent to the CPU and hence does not impact the performance of the switch.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

68

CGMP Messages
GDA
Mcst MAC Mcst MAC 00000000 00000000 Mcst MAC 00000000

USA
Client MAC Client MAC Router MAC Router MAC 00000000 00000000

Join/Leave Meaning
Join Leave Join Leave Leave Leave Add USAs port to the Group Delete USAs port from Group Assign Port = Router Port Deassign Port = Router Port Delete Group from CAM Delete ALL Groups from CAM

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

69 69

CGMP Messages
All of these messages are sent by the router (switches do not originate CGMP messages) All of these messages are contained within a given VLAN When a JOIN is sent with a non-zero GDA and a non-zero USA, this adds the switch port where USA is located to the given group list in the CAM table (normal operation after a router receives an IGMP JOIN) When a LEAVE is sent with a non-zero GDA and a clients MAC address for the USA, that clients port is deleted from the group (selectively delete a single client based on an IGMP leave) When a JOIN is sent with a GDA of all zeros using its own MAC address as the USA, this is an advertisement for the switches to detect what incoming switch ports are router ports (occurs every 60 seconds so switches can dynamically find the CGMP-speaking routers) When a LEAVE is sent with an all-zeros GDA and a USA of the routers MAC, all groups and ports are deleted that are associated with that router port (the router has withdrawn its CGMP ability) When a LEAVE is sent with a non-zero GDA and an all zeros USA, this globally deletes the group in all switches (used to globally delete the group after the last member has left via IGMP state) When a LEAVE is sent with all zeros in GDA and USA, all groups are deleted in all switches (occurs when CGMP is disabled on the router or a clear ip cgmp is executed for a given router interface/VLAN)

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

69

CGMP Router Commands


Command
ip cgmp ip cgmp proxy

Notes
Enable CGMP per (Sub) Interface Enables CGMP and DVMRP Proxy per (Sub) Interface Debugs CGMP Activity Shows if CGMP Is Enabled or Disabled Clears All CGMP Groups

debug ip cgmp show ip igmp interface [int [int] ] clear ip cgmp [int int] ]

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

70 70

CGMP Router Commands


All you really need to know is the first command for the majority of installations!

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

70

CGMP Switch Commands

Command
set cgmp enable|disable show multicast router show multicast group show cgmp statistics clear cgmp statistics

Notes
Globally Enable or Disable cgmp Displays Which Ports Are Router Ports Shows which Groups Are Active Shows CGMP Statistics Clears CGMP Statistics

Note: Cat5000 series switch commands shown.


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

71 71

CGMP Switch Commands


All you really need to know is the enable form of the first command for the majority of installations!

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

71

CGMP Switch Commands

Command
set multi router <mod/port> clear multicast router <mod/port> set cgmp leave <en|dis <en|dis> >

Notes
Designates port a router port Deletes multicast router port information Enables/disables fast leave processing

Note: Cat5000 series switch commands shown.


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

72 72

CGMP Switch Commands


The set multi router <mod/port> command may be used to manually designate a port as having a router attached. This might be necessary if the router connected to this port is running some non-standard multicast protocol that the switch does not recognize.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

72

SummaryFrame Switches
IGMP snooping
Switches with Layer 3 aware ASICs
High-throughput performance maintained Increases cost of switches

Switches without Layer 3 aware ASICs


Suffer serious performance degradation

CGMP
Requires Cisco routers and switches Can be implemented in low -cost switches
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

73 73

Summary
IGMP Snooping can actually provide some performance optimizations over CGMP. However, it requires switches that are implemented with more costly Layer 3 aware ASICs in order to avoid performance impacts. CGMP is a proprietary protocol that is only implemented on Cisco routers and switches and does not have quite as many performance optimizations that IGMP Snooping can offer. However, it is the ONLY choice if one desires to provide Layer 2 multicast traffic constraint on low-end switches such as the Cisco Catalyst 1900 or other equivalent switches.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

73

Design Issue Server Location

Multicast Traffic Being Dropped!!! Unnecessary Traffic!!!


Catalyst 5000
VLAN1 Catalyst 29xx Catalyst 29xx Catalyst 29xx VLAN2 VLAN3

Video Server
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

74 74

Layer 2 Design Issues Server Location


IGMP Snooping and CGMP do not solve all problems related to multicast traffic constrainment in Layer 2 networks. Given a typical Layer 2 switch network where a high-end central switch is trunked to closet switches, unwanted traffic can still wind up flowing over inter-switch trunks.

Example:
In the above drawing, the Video Server is located on one of the ports of the 2900 closet switches. This server is sourcing high-rate video for which there are no receivers in the LAN switching environment. However, the IP Multicast host model defined in RFC 1112 requires that this traffic flow must at all times be sent to the router. This results in traffic flowing over the inter-switch trunk that may not be necessary. Certainly, if there are no receivers beyond the router, this traffic flow is just wasting trunk bandwidth.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

74

Design Issue Server Location

Multicast Traffic Still Being Dropped!!!


Video Server

Catalyst 5000
VLAN1 VLAN2 VLAN3

Catalyst 29xx

Catalyst 29xx

Catalyst 29xx

Keep high B/W sources close to router


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

75 75

Layer 2 Design Issues Server Location


By paying attention to this possibility in the design of the net work, the impact can be reduced. In the above example, the high-rate video server has been moved as close as possible to the router. This eliminates the possibility of unnecessary traffic flowing on the inter-switch trunks. There is another way to solve this problem and that is to replace the switches with routers. It is only at Layer 3 that complete control of multicast flows is possible.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

75

Design IssueCore Switch


Video Server

Router A

7500
1.5MB MPEG Video Streams

Unnecessary Multicast Traffic !!!

Holy Multicast, Batman!! 3MB of unwanted data! (Choke, gasp, wheeze!)

T1

Catalyst 5000

2500 2500

WAN

Router D

Router B

7500

Unnecessary Multicast Traffic !!!

7500
Receiver Group 2

Router C

Receiver Group 1

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

76 76

Layer 2 Design Issues Core Switch Issues


In the case of a core network composed of several routers on an Ethernet segment, IGMP Snooping and CGMP provide absolutely no help in the constraint of multicast traffic flows. This is because routers do not send IGMP Membership Reports for desired multicast flows. (They use PIM control messages or some other routing protocol control messages instead.)

Example:
Consider the network shown in the drawing above. Three campus routers are connected via 100Mbps Ethernet to a core switch. A video server connected to Router A is sourcing two 1.5Mbps MPEG video multicast streams, one to Group 1 and another to Group 2. Router B has a directly connected member of Group 1 and therefore needs the 1.5Mbps Group 1 video stream. Router C has a directly connected member of Group 2 and therefore needs the 1.5Mbps Group 1 video stream. Because both Routers B & C are on the same Ethernet segment (albeit on different ports on the switch), they each receive both Group 1 & 2 video streams even though they only need one. Even worse, Router D has been connected to this core backbone Ethernet segment for the purpose of supplying remote sites with unicast connectivity and low rate multicast. (i.e. there is no intention of sending MPEG video to the remote sites.) Unfortunately, the little 2500 will also receive both of the high-rate video streams for a total of 3Mbps of unwanted traffic! While the 2500 is capable of fast-dropping the unwanted traffic in the fastswitching path, it still has a significant impact on the performance of the router.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

76

Design Issue Core Switch


Video Server

Router A

7500
1.5MB MPEG Video Streams
2500 2500

T1

WAN

Router-D

Catalyst 5000

Move WAN Router to Another VLAN Segment Inside of Catalyst 5000

Router B

7500

Unnecessary Multicast Traffic !!!

7500
Receiver Group 2

Router C

Receiver Group 1

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

77 77

Layer 2 Design Issues Core Switch Issues


While todays technology can not solve this problem (it would basically require the switch to run PIM which means it must become a router and not a switch), this problem can be address by proper network design.

Solution
By connecting Router D to a separate LAN segment off of Router A (this could be accomplished using another port on Router A and a separate VLAN in the Cat5000), Router D is able to prune off any unwanted traffic. Exercise 1: Why is this now possible? (See answer below.) Unfortunately, we still have unwanted traffic flowing to Routers B & C. One might argue that the same solution used for Router D could be used which is true. However, this would require additional Ethernet ports on Router A. The other solution would be to use multiple VLANs on the single Ethernet port on Router A. Unfortunately, this would significantly reduce the overall bandwidth available and is a sub-optimal solution.

Answer to Exercise 1: Because there is no other router on the LA N segment, Router A is able to Prune off the traffic flow without the Prune being overridden by another router on the LAN segment.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

77

Design Issue Core Switch


Problem
Routers send PIM Join/Prunes at Layer 3
IGMP Join/Leaves not sent by routers Other routers on VLAN can override Prune

Switches operate at Layer 2


Use IGMP Snooping to constrain multicast Must assume routers want all multicast traffic

Need new Layer 2 Join/Prune mechanism


Permits routers to send Join/Prunes to switch

Solution: (RGMP)
Router Group Management Protocol
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

78 78

Design Issue Core Switch


Routers do not send IGMP Membership reports or IGMP Leaves to communicate their desire to receive multicast traffic. Instead, they communicate at Layer 3 using PIM Join/Prune messages. However, when sending a PIM (*,G) Prune message to indicate they do not want a particular multicast group, another router on the VLAN can override the Prune. Switches only operate at Layer 2 (otherwise they would be routers). They listen to IGMP messages to constrain the flow of multicast traffic to hosts that wish to receive a particular multicast group. Because routers do not send IGMP membership reports, the switches must assume that the routers want all multicast traffic. (This is an assumption of the basic multicast model defined in RFC 1112.) In order to constrain multicast traffic between routers on a core LAN segment, routers and switches need some form of Layer 2 Join/Prune communication that permits the routers to inform the switch of which groups it has interest. Cisco has developed the Router Group Management Protocol (RGMP) to accomplish this communication.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

78

Router Group Management Protocol


Runs on Core Routers and Switches
Routers
Identify themselves via RGMP Hello/Bye msg. Send special Layer 2 (*,G) Join/Prune messages.

Switches
Do not forward multicast traffic to router ports until specifically requested.

Limitations:
Only works with PIM-SM/PIM-SSM No Hosts permitted on VLAN
Routers cannot detect sources since multicast flooding to routers is off by default.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

79 79

Router Group Management Protocol


RGMP is enabled on core routers and switches. This enables the routers to inform the switches of which multicast group traffic it needs to receive. Routers send special Layer 2, RGMP (*,G) Join/Prune messages to the switches. Switches, by default, do not forward any multicast traffic to the routers. Instead, they wait for RGMP (*,G) Join messages from the routers to tell them when to begin forwarding multicast group traffic. Limitations: RGMP requires the use of PIM-SM to operate properly. RGMP is intended for use only on a VLAN used as a router backbone. No multicast hosts should be used on a VLAN configured for RGMP. This is because any multicast traffic sourced by a host may not be heard by the routers since RGMP blocks multicast traffic to the routers by default. This could prevent the DR on this VLAN from knowing that there is an active source which would in turn, prevent the source from being registered to the RP.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

79

RGMP
Initially, multicast forwarding to routers is disabled
RGMP Switch

CPU

Switching Engine

CAM Table
1
MAC Address 0100.5exx.xxxx Ports

2 B C

3 D

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

80 80

RGMP Example:
Consider the LAN segment running through the above switch that has four routers connected in a core router backbone. Initially, RGMP blocks all multicast traffic from reaching the routers by the wildcard CAM table entry.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

80

RGMP
1st Router receives a PIM (*,G) Join from downstream
RGMP Switch

CPU

Switching Engine
RGMP Join
0100.5e01.0101

CAM Table
1
MAC Address 0100.5exx.xxxx 0100.5e01.0101 0100.5exx.xxxx Ports 2

2 B C

3 D

Entry Added

PIM (*, 224.1.1.1) Join


8/9/2001 4:20 PM

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

81 81

RGMP Example:
When router B receives a downstream PIM (*,G) Join for group 224.1.1.1, it sends an RGMP Join for the corresponding MAC address, 0x0100.5e01.0101. When the switch receives the RGMP Join message, it instantiates an entry in its CAM table for 0x0100.5e01.0101 with the port number of the sending router.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

81

RGMP
2nd Router receives a PIM (*,G) Join from downstream
RGMP Switch

CPU

Switching Engine
RGMP Join
0100.5e01.0101

CAM Table
1
MAC Address 0100.5e01.0101 0100.5exx.xxxx Port Added Ports 2,4

2 B C

3 D

PIM (*, 224.1.1.1) Join


1998 2001, Cisco Systems, Inc. All rights reserved.

Module2. ppt

8/9/2001 4:20 PM

82 82

RGMP Example:
When router D receives a downstream PIM (*,G) Join for group 224.1.1.1, it too sends an RGMP Join for the corresponding MAC address, 0x0100.5e01.0101. When the switch receives the RGMP Join message from router D, it updates the entry in its CAM table for 0x0100.5e01.0101 by adding the port number associated with router D.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

82

RGMP
Multicast is constrained to routers B and D
RGMP Switch

CPU

Switching Engine

CAM Table
1
MAC Address 0100.5e01.0101 0100.5exx.xxxx Ports 2,4

2 B C

3 D

Source
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

83 83

RGMP Example:
When a source behind router B begins transmitting to group 224.1.1.1, router B forwards this traffic to the core router backbone (the switch). The CAM table entry in the switch now effectively constrains the multicast traffic to routers B and D. Routers A and C, which have not joined the multicast group, do not receive the traffic.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

83

Design Issue 224.0.0.x Flooding


Router A 1 LAN Switch
OSPF Hello (224.0.0.5)

CPU

Switching Engine

CAM Table
2
MAC Address Ports

Host 1

Router B

Router C

Router D
8/9/2001 4:20 PM

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

84 84

Layer 2 Design Issue 224.0.0.x Flooding


By default, all Cisco switches flood multicast traffic addressed to 224.0.0.x. to all ports on the switch. More specifically, any traffic addressed to 0x0100.5e00.00xx is flooded. This means that this includes not only 224.0.0.x address but 225.0.0.x, 226.0.0.x, etc., etc. This is done in order to avoid problems with protocols such as OSPF, EIGRP, DVMRP, PIM and many others that make use of link-local multicast to addresses in the 224.0.0.x range. If this was not done, problems could occur that cause the flow of traffic in these ranges to be inadvertently constrained thereby breaking these protocols.

Example:
Consider the OSPF LAN segment running through the above switch that has four OSPF routers plus one host. Because there is no entry in the CAM Table for the MAC address equivalent of 224.0.0.5 (OSPF Router Hello), the OSPF Hello messages are being flooded to all OSPF routers on the segment and OSPF adjacency is being maintained.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

84

Design Issue 224.0.0.x Flooding


Router A 1 LAN Switch
IGMP Report 224.0.0.5

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e00.0005 Ports 2

Entry Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Host 1

Router B

Router C

Router D
8/9/2001 4:20 PM

85 85

Layer 2 Design Issue 224.0.0.x Flooding Example (cont.)


Now lets assume that for some (perverse) reason, Host 1 decides to Join group 224.0.0.5 and therefore sends an IGMP Membership Report for this group. (This might be caused by a multicast application that is launched with an incorrect group address in the command line or simply by a hacker wishing to mess with the network.) Assuming the switch is doing IGMP Snooping or CGMP and does not automatically flood traffic in this range it might respond to the IGMP Membership Report by instantiating an entry in the CAM Table to constrain the flow of 224.0.0.5 multicast traffic to just Host 1.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

85

Design Issue 224.0.0.x Flooding


Router A 1 LAN Switch
OSPF Hello (224.0.0.5)

CPU

Switching Engine

CAM Table
2
MAC Address 0100.5e00.0005 Ports 2

Host 1

Router B

Router C

Router D
8/9/2001 4:20 PM

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

86 86

Layer 2 Design Issue 224.0.0.x Flooding Example (cont.)


As a result of blindly instantiating this CAM Table entry, further OSPF Hello traffic is constrained to Host 1. This results in OSPF adjacency being lost between all OSPF routers on this segment. Care should be taken when purchasing non-Cisco switches as some vendors will behave as shown in this example which can cause problems.

Note:
This is a hotly debated issue in the IETF that stems from the fact that the IGMPv2 spec states that with the exception of 224.0.0.2, all devices MUST join the multicast group in order to receive traffic from the group. Unfortunately, this implies that all router vendors must rewrite their existing routing protocols (such as OSPF) so that the router sends IGMP Membership Reports for such groups as All OSPF Routers, 224.0.0.5, All OSPF DRs, 224.0.0.6, All EIGRP Routers, 224.0.0.10, etc., etc. This is clearly an absurd idea as even if all vendors did rewrite their implementations to be compliant with the new IGMP spec, it would mean that the customer would have to wholesale upgrade all routers in the network in a flag day. This might even require changing out router hardware in order to be able to run the latest code. For this reason, Cisco has chosen to address this problem by having all switches flood any IP multicast traffic with a destination MAC address falling in the range of 0x0100.5e00.00xx. This guarantees that protocols that use linklocal multicast will continue to function properly.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

86

Design Issue Address Overlap

Try to Avoid Addresses that Must Be Flooded


32 - IP Multicast Addresses 224.0.0.x 224.128.0.x 225.0.0.x 225.128.0.x . . . 238.0.0.x 238.128.0.x 239.0.0.x 239.128.0.x
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

1 - Multicast MAC Address

0x0100.5E00.00xx

8/9/2001 4:20 PM

87 87

Layer 2 Design Issue 224.0.0.x Flooding Example (cont.)


The implication of this requirement to flood all traffic addressed to a destination MAC address in the 0x0100.5e00.00xx range means that there is a large range of Layer 3 IP multicast addresses that fall into this range as shown in the drawing above. This problem is particularly true for low-end switches that do not have the capability to differentiate between link -local traffic flows addressed to 224.0.0.xx and traffic flows addressed to valid global multicast addresses such as 225.0.0.xx.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

87

Design Issue Address Overlap

Dont forget about 32:1 overlap when selecting group addresses


32 - IP Multicast Addresses 224.1.1.1 224.129.1.1 225.1.1.1 225.129.1.1 . . . 238.1.1.1 238.129.1.1 239.1.1.1 239.129.1.1

1 - Multicast MAC Address

0x0100.5E01.0101

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

88 88

Layer 2 Design Issue Address Overlap


Remember to fact in the overlap of Layer 3 addresses into Layer 2 addresses when selecting multicast addresses. Failure to do so can result in hosts receiving unwanted multicast traffic that the switch is unable to differentiate.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

88

SummaryDesign Issues
Pay attention to campus topology
Be aware of unwanted flooding over trunks

Use IGMP snooping and/or CGMP


Neither can solve all L2 flooding issues To solve all problems requires multicast routing
Or a more robust CGMP-like protocol (hint)

224.0.0.x flooding
Watch out for switches that dont flood 224.0.0.x traffic

Address overlap
Select group addresses to avoid L2 overlap Avoid x.0.0.x group addresses when possible
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

89 89

Design Issues Summary


Topology Watch your campus topology when designing you network for multicast and beware of the possibility of unwanted traffic over inter-switch trunks. Use IGMP Snooping and/or CGMP This will help constrain multicast traffic to hosts that have requested it. Keep in mind that not all situations are covered by IGMP Snooping or CGMP and that traffic is not always constrained under certain conditions. 224.0.0.x Flooding Watch out for vendor switches that do not flood multicast traffic in these ranges. Misbehaved or misconfigured hosts can cause this critical traffic to be shutoff in switches that do not flood this traffic. Address Overlap Try to select multicast addresses so that different applications dont map their multicast streams into the same L2 MAC address due to the 32:1 overlap of IP group addresses at Layer 2. Avoid *.0.0.* and *.128.0.* multicast addresses when possible as these ranges are flooded by Cisco switches.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

89

Multicast over ATM LANE Core

BUS

Unwanted Data!!!
Source Member
8/9/2001 4:20 PM

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

90 90

Multicast over an ATM Lane Core Network


The nature of ATM LANE hides the underlying ATM topology from the routers which can result in the inefficient use of bandwidth in the core.

Multicast flow over ATM LANE


All multicast traffic flows through the Broadcast/Unknown Server (BUS) in the multicast ELAN. This is shown in the drawing above. Each LAN Emulation Client (LEC) in the network (in this case the routers) each have a p2p VC to the BUS. Any broadcast/multicast or unknown traffic is sent by the router to the BUS for distribution to all other routers in the ELAN. The BUS has a p2mp VC that connects all the BUS device to all other routers in the network. In the above example, multicast traffic is flowing from the source, through the router to the BUS via the p2p VC. From there, the BUS sends the traffic to all routers in the core ELAN vi the p2mp VC. Note that in the above example, this traffic is being sent to routers that have no need for the traffic and is therefore wasting bandwidth in the ATM core.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

90

Multicast over ATM LANE Core


Make Sure Your BUS Device Can Handle the Maximum Expected Load!

BUS

1.5Mbit MPEG Video


Source

Make Sure Your ATM Switches Can Replicate Cells at this Rate!

Member

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

91 91

Multicast flow over ATM LANE


The higher the rate of traffic being sourced, the greater the amount of bandwidth being wasted in the ATM core. Care must be take to insure that the BUS device selected can handle the total flow of multicast traffic. Care must also be take to insure that the ATM switches in the network are capable of replicating cells at the rates necessary so that traffic is not lost along the p2mp VC.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

91

Multicast over ATM LANE Core


Why do I have to do all the work?! ELAN 1 ELAN 2

BUS

Avoid using a single device as BUS for multiple ELANs

ELAN 3

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

92 92

Multicast over an ATM Lane Core Network


A frequently made mistake is to assign the duties of the BUS device of several ELANs to a single physical device. This can often result in an overloaded BUS device.

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

92

Multicast over ATM LANE Core


Design issues
BUS horsepower is critical
Use separate BUS device per ELAN to reduce load Overloaded BUS = cell/packet loss and jitter/delay
Can cause problems on multimedia conferences

ATM switch cell replication rate is critical


Switches that replicate cells in hardware are best

Add lots of bandwidth to ATM fabric


Traffic will frequently be sent where its unwanted ATM core bandwidth will be wasted

P2MP VCs may be a better solution


Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/9/2001 4:20 PM

93 93

Multicast over an ATM Design Issues


Bus Horsepower Make sure that the BUS device selected has sufficient horsepower to forward the expected multicast traffic flows. Use separate physical devices for BUS devices on different ELANs ATM Switch Horsepower Make sure that the ATM switches are capable of replicating cells at the expect multicast traffic rates. Bandwidth Account for the inefficient use of ATM bandwidth when multicasting over an ATM core network. Remember that traffic is often sent where it is unwanted, thereby wasting bandwidth. Consider alternatives to using ATM LANE

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

93

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

94

Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

94

PIM Dense Mode


Module 3

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

Module Objectives

Identify and explain the basic mechanisms of PIM Dense Mode. Identify the packet types used by PIM Dense Mode. Configure and verify normal PIM DM operation.

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

2 2

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

Module Agenda

Geekometer

PIM Dense Mode Overview PIM Packet Formats PIM Dense Mode Concepts PIM Dense Mode Review Configuring PIM Dense-Mode

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

3 3

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Dense Mode Overview

Uses Push Model


Traffic is initially flooded to all PIM neighbors Branches that dont want data are pruned

Multicast forwarding state is created by the arrival of data If the source goes inactive, the tree is torn down

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

4 4

The PIM Dense Mode Push Model


This model assumes that there are members at all points in the network, hence the concept of a dense distribution of receivers. Routers initially flood Multicast traffic out all interfaces where there is: Another PIM-DM neighbor or A directly connected member or An interface that has been manually configured to join the group. Branches that do not have members send Prune messages toward the source to prune off the unwanted/unnecessary traffic. These pruned branches timeout after 3 minutes and traffic is re-flooded down the branch. Due to this periodic re-flooding, dense mode is more applicable when bandwidth is plentiful as bandwidth is wasted due to re-flooding.

In Dense mode, multicast state is created by data arrival


In PIM Dense mode, the control plane and the data plane are one in the same. This implies the following: (S, G) state, and hence the Source Tree, is created on the fly by the arrival of (S, G) multicast traffic. (S, G) state, and hence the Source Tree, is deleted when the source goes inactive and no multicast traffic is received by the router for 3 minutes. Because the control plane and data plane are mixed in PIM Dense mode, its maintenance of the Source Tree is considerably less deterministic than Sparse mode. This can sometimes result in instabilities and temporary loss of data during some network topology changes. Dense mode only has source trees - no shared trees are used
Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Dense Mode Overview

Grafts are used to join existing source tree Asserts are used to determine forwarder for multi-access LAN Prunes are sent on non-RPF P2P links
Asserts are sent on non-RPF multi-access links

Rate-limited prunes are sent on all P2P links

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

5 5

PIM Dense Mode Grafting


PIM Graft messages are used to reduce the join latency when a previously pruned branch of the Source Tree must be grafted back. This can be the case when a member joins the group after the router has sent a Prune message to prune off unwanted traffic. If Grafts were not used, the member would have to wait up to three minutes for the periodic re-flooding to occur to begin receiving the multicast traffic. By using Grafts, the Prune can be reversed almost immediately.

PIM Dense Mode Asserts


When two routers both forward the same (S, G) multicast traffic onto a common multi-access LAN, duplicate traffic is generated. When this occurs, Assert messages are generated by both routers to determine which router should continue forwarding on the LAN and which router(s) should stop (prune).

PIM Dense Mode Pruning


When data arrives on non-RPF interface (i.e. an interface that is not used to reach the source) and the interface is point-to-point (P2P), a Prune is immediately sent to the upstream neighbor in an attempt to shut off the flow of traffic. Note that when data arrives on a non-RPF interface that is not a P2P (i.e. multi-access) interface, an Assert is triggered instead of a Prune. Rate-limited Prunes are sent on all P2P interfaces. This means that if data continues to arrive on a non-RPF, P2P interface, rate-limited Prunes are sent. Rate-limited Prunes are also sent on the RPF interface of P2P links when it is necessary to Prune the flow of traffic.
Copyright ? ?1998-2001, Cisco Systems, Inc.
Module3.ppt

PIM Dense Mode Overview

Initial Flooding

Source

Multicast Packets

(S, G) State created in every router in the network!

Receiver
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

6 6

Initial Flooding
In this example, multicast traffic being sent by the source is flooded throughout the entire network. As each router receives the multicast traffic via its RPF interface (the interface in the direction of the source), it forwards the multicast traffic to all of its PIM-DM neighbors. Note that this results in some traffic arriving via a non-RPF interface such as the case of the two routers in the center of the drawing. (Packets arriving via the non-RPF interface are discarded.) These non-RPF flows are normal for the initial flooding of data and will be corrected by the normal PIM-DM pruning mechanism.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Dense Mode Overview

Pruning unwanted traffic

Source

Multicast Packets Prune Messages Receiver


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

7 7

Pruning unwanted traffic


In the example above, PIM Prunes (denoted by the dashed arrows) are sent to stop the flow of unwanted traffic. Prunes are sent on the RPF interface when the router has no downstream members that need the multicast traffic. Prunes are also sent on non-RPF interfaces to shutoff the flow of multicast traffic that is arriving via the wrong interface (i.e. traffic arriving via an interface that is not in the shortest path to the source.) An example of this can be seen at the second router from the receiver near the center of the drawing. Multicast traffic is arriving via a non-RPF interface from the router above (in the center of the network) which results in a Prune message.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Dense Mode Overview

Results after Pruning

Source

Multicast Packets

(S, G) State still exists in every router in the network!

Flood & Prune process repeats every 3 minutes!!!


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Receiver
8/10/2001 11:41 AM

8 8

Results after Pruning


In the final drawing in our example shown above, multicast traffic has been pruned off of all links except where it is necessary. This results in a Shortest Path Tree (SPT) being built from the Source to the Receiver. Even though the flow of multicast traffic is no longer reaching most of the routers in the network, (S, G) state still remains in ALL routers in the network. This (S, G) state will remain until the source stops transmitting. In PIM -DM, Prunes expire after three minutes. This causes the multicast traffic to be re-flooded to all routers just as was done in the Initial Flooding drawing. This periodic (every 3 minutes) Flood and Prune behavior is normal and must be taken into account when the network is designed to use PIM-DM.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Packet Formats

PIM Packet Headers PIM Hello Messages PIM Join/Prunes PIM Grafts/Graft Acks PIM Asserts

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

9 9

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

PIM Packet Formats (SM Only)

PIM Registers PIM Register-Stop

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

10 10

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

10

PIMv1 Packet Header


3 Type Ver. 7 Code Reserved Type: 0x14 = PIM Message 15 Checksum 31

PIMv1 used IGMP Packets

Code: 0 = Router-Query 1 = Register (SM only) 2 = Register-Stop (SM only) 3 = Join/Prune 4 = RP-Reachibility (SM only) 5 = Assert 6 = Graft 7 = Graft-ACK Ver: PIM Version = 1

PIMv1 messages are multicast to the ALL-Routers (224.0.0.2) group with a TTL of 1.
Note: (PIMv1 packet formats are not shown. Only PIMv2 packets wi ll be given.)
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

11 11

PIM (v1) Packet Headers


An IGMP type code of 0x14 indicates the frame is carrying a PIMv1 message the code field then determines the type of PIM messages. PIMv1 messages are multicast to the ALL-Routers (224.0.0.2) multicast group address with a TTL of 1. This means that these control messages are Link-Local in scope.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

11

PIMv2 Packet Header


PIMv2 is assigned protocol number 103
3 Ver. 7 Type Reserved 15 Checksum 31

Ver: PIM Version = 2 Type: 0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft 7 = Graft-Ack 8 = C-RP-Announcement

(SM only) (SM only) (SM BSR only) (DM only) (DM only) (SM BSR only)

PIMv2 messages are multicast to the ALL-PIM-Routers (224.0.0.13) group with a TTL of 1.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

12 12

PIM (v2) Packet Headers


PIMv2 packets are encoded in their own protocol packets using PIM assigned protocol number of 103. The Type field then determines the type of PIMv2 message. PIMv2 messages are multicast to the ALL-PIM-Routers (224.0.0.13) multicast group address with a TTL of 1. This means that these control messages are Link-Local in scope.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

12

PIM Hello Messages


3 Ver. 7 Type Reserved 15 Checksum Option Length Option Value ... Option Type OptionValue OptionLength 31

Option Type

Option Types: 1 = Holdtime (Period of time in seconds before this PIM neighbor times out.) 19 = DR Priority 20 = Generation ID
13 13

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

PIMv2 Hello Messages


PIMv2 Hello messages are used to form and maintain neighbor adjacencies They are sent periodically to indicate to the other PIM routers on the network that this PIM router is still present. The PIMv2 Hello message format defines numerous Option TLVs which include: Holdtime: This specifies the time in seconds that this neighbor is reachable. A value of 0xffff indicates the neighbor never times out. A value of 0x0000 means the neighbor is immediately timed out. DR Priority: This value can be used in the election of the DR for the subnet. Generation ID: This is a random 32-bit value that is sent whenever the neighbor actives PIM on the interface. It can be used to determine when the neighbor has been reactivated after a failure.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

13

PIM Join/Prune Packets


3 Ver. 7 Type Reserved 15 Checksum 31 Upstream Neighbor Address: IP address of RPF of upstream neighbor Holdtime: Period of time in seconds before this join/prune times out. Num. Grps # of Groups in Group list Group List: List (by group) of sources to Join and/or Prune

Upstream Neighbor Address (Encoded-Unicast) Reserved Num. Groups Holdtime

Group List

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

14 14

PIM Join/Prune Packets


The JOIN/PRUNE is a single packet format that contains a list of Joins and a list of Prunes. Either list may be empty (although not both).

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

14

PIM Group Lists


0 Number of Join Sources 15 Group-1 (Encoded-Group) Number of Prune Sources Group- x Group IP Address Number of Join Sources # of Joins for Group- x Number of Prune Sources # of Prunes for Group- x Join/Prune Source - x Encoded Source address to be Joined/Pruned 31

Join Source-1 (Encoded-Source) Join Source-n (Encoded-Source) Prune Source-1 (Encoded-Source) Prune Source-n (Encoded-Source) Group-2 (Encoded-Group) Number of Join Sources Number of Prune Sources

Group Lists are used in Join/Prune and Graft/Graft-Ack messages.


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

15 15

Group Lists
Group Lists are used in Join/Prune messages as well as Graft and Graft -Ack messages. A Group List is a list of Group entries each beginning with a Group IP Address and Group mask to identify the Multicast Group. Each Group List entry contains a list of zero or more sources to Join followed by a list of zero or more sources to Prune. Group IP Address Number of Join Sources Number of Prune Sources Join List Prune List The addresses used in Join and Prune lists use a special encoded format that allows for other protocols besides IPv4. (See next slides.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

15

Encoded Unicast Addresses


3 7 10 15 Addr Family Encoding Type Unicast Address Addr Family: IANA Address Family Identifier (1=IPv4) Encoding Type: Type of encoding within Address Family Unicast Address : Unicast Address of the target device. 31 Unicast Address ...

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

16 16

Encoded Unicast Addresses


The Unicast Addresses contained in the Join and Prune Lists of a Group List entry are encoded in a special format as shown in the slide above. Address Family Indicates the IANA Address Family Identifier. For IPv4, this value is 1. Encoding Type Indicates the encoding type within the Address Family. Unicast Address IP unicast address of the target device.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

16

Encoded Source Addresses


3 7 10 15 Addr. Family Encoding Type Rsvd Source Address Addr Family: IANA Address Family Identifier (1=IPv4) Encoding Type: Type of encoding within Address Family S = Sparse Mode bit : Indicates sparse mode group. Rcvrs must send periodic joins. W = Wildcard bit : Indicates join/prune applies to (*, G) entry. R = RP bit : Indicates this join/prune should be sent up the Shared Tree towards the RP. Mask Length: Number of bits in the prefix of the Group Address. Source Address : Address of Multicast Source.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

23 SWR

31 Mask Len

8/10/2001 11:41 AM

17 17

Encoded Source Addresses


The Source Addresses contained in the Join and Prune Lists of a Group List entry are encoded in a special format as shown in the slide above. Address Family Indicates the IANA Address Family Identifier. For IPv4, this value is 1. Encoding Type Indicates the encoding type within the Address Family. S = Sparse Mode bit Used by routers on the Shortest-Path Tree (SPT) to indicate the group is a sparse mode group which tells the receiver of this join that it must send periodic Joins toward the source. W = Wildcard bit Indicates that the Join/Prune applies to the (*, G) entry. If this bit is cleared, it indicates that this applies to an (S, G) entry. Joins and Prunes sent to the RP should have this bit set. R = RP bit Indicates that this information should be sent up the Shared Tree towards the RP. If this bit is clear, the information should be sent up the ShortestPath Tree toward the source. M. Len Mask length in bits. Source Address IP address of the Source.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

17

Encoded Group Addresses


3 7 10 15 23 Addr. Family Encoding Type Reserved Group Address Addr Family: IANA Address Family Identifier (1=IPv4) Encoding Type: Type of encoding within Address Family Mask Length: Number of bits in the prefix of the Group Address. Group Address : Multicast Group Address. 31 Mask Len

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

18 18

Encoded Group Addresses


Group Addresses contained in the Join and Prune Lists of a Group List entry are encoded in a special format as shown in the slide above. Address Family Indicates the IANA Address Family Identifier. For IPv4, this value is 1. Encoding Type Indicates the encoding type within the Address Family. M. Len Mask length in bits. Group Address IP multicast group address.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

18

PIM Graft/Graft-Ack Packets


3 Ver. 7 Type Reserved 15 Checksum 31 Upstream Neighbor Address: IP address of RPF of upstream neighbor Holdtime: Period of time in seconds before this join/prune times out. Group List Num. Grps # of Groups in Group list Group List: List (by group) of sources to Graft or Graft-Ack

Upstream Neighbor Address (Encoded-Unicast) Reserved Num. Groups Holdtime

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

19 19

PIM Graft/Graft-Ack Packets


Graft/Graft-Ack are used in dense mode for grafting onto the tree These are the only PIM messages that are sent reliably (I.e. get an acknowledgement)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

19

PIM Assert Packets


3 Ver. 7 Type Reserved 15 Checksum 31 Group Address (Encoded-Group) Source Address (Encoded-Source) R Metric Preference Metric Group Address: Identifies Group of the Assert Source Address: Identifies Source of the Assert R: (Sparse Mode) 1 = Assert down RP Tree; 0 = Assert Down SPT Metric Preference: Admin. Distance of unicast routing protocol Metric: Unicast routing protocol metric
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

20 20

PIM Assert Packets


Assert messages determine who will be the active forwarder when there is redundancy in the network toward the source If the same routing protocol is used between the redundant neighbors, the metric is compared and the best metric wins In the case of an equal cost metric with the same routing protocol - the highest IP address neighbor will break the tie In the case where dissimilar unicast routing protocols are used, a metric preference is used to weight the preferred order of the routing information of each unicast routing protocol (like administrative distance)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

20

PIM Register Packets


Sparse Mode Only
3 Ver. BN 7 Type Reserved Reserved 15 Checksum 31

Multicast Data Packet

B = Border Bit: Indicates DR is a border router performing a proxy-register N = Null Register Bit: Indicates DR is sending a Null-Register before expiring its register-suppression timer. Multicast Data Packet: The original packet sent by the source. For periodic sending of registers, this part is null.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

21 21

PIM Register Packets


Used in SM by the DR to encapsulate multicast packets and send them to the RP so they may be forwarded down the shared tree. Register messages with encapsulated multicast packets continue to be sent to the RP by the DR until a Register-Stop message is received from the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

21

PIM Register-Stop Packets


Sparse Mode Only
3 Ver. 7 Type Reserved 15 Checksum 31

Group Address (Encoded-Group) Source Address (Encoded-Source)

Group Address: The group address from the register message. Source Address: IP host address of source from multicast data packet in register.

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

22 22

PIM Register-Stop Packets


Used in SM by the RP to inform the DR to stop sending Register messages. This message is sent after the RP has joined the source tree to the DR and is receiving the multicast traffic natively via the SPT.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

22

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Forwarding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

23 23

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

23

PIM Neighbor Discovery


171.68.37.2 PIM-DM Router 2 Highest IP Address elected as DR (Designated Router) PIM Query

PIM Query PIM-DM Router 1 171.68.37.1 PIM Queries are Multicast to the All-Routers (224.0.0.2) (with a TTL of 1) multicast group address periodically. (Default = 30 seconds ) If the DR times-out, a new DR is elected. In PIM DM, interface is added to outgoing interface list for all groups when first neighbor is heard.

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

24 24

PIM Neighbor Discovery


PIM Queries are sent periodically to discover the existance of other PIM routers on the network. For Multi-Access networks (e.g. Ethernet), the PIM Query message is multicast to the All-Routers (224.0.0.2) multicast group address.

Designated Router (DR)


For Multi-Access networks, a Designated Router (DR) is elected. In PIM Sparse mode networks, the DR is responsible for sending Joins to the RP for hosts on the Multi-Access network. For Dense mode, the DR has no meaning. The exception to this is when IGMPv1 is in use. In this case, the DR also functions as the IGMP Querier for the Multi-Access network.

Designated Router (DR) Election


To elect the DR, each PIM node on a Multi-Access network examines the received PIM Query messages from its neighbors and compares the IP Address of its interface with the IP Address of its PIM Neighbors. The PIM Neighbor with the highest IP Address is elected the DR. If no PIM Querys have been received from the elected DR after some period (configurable), the DR Election mechanism is run again to elect a new DR.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

24

PIM Neighbor Discovery


wan-gw8> show wan-gw8> show ip ip pim pim neighbor neighbor PIM PIM Neighbor Neighbor Table Table Neighbor Neighbor Address Address Interface Interface 171.68.0.70 FastEthernet0 171.68.0.70 FastEthernet0 171.68.0.91 FastEthernet0 171.68.0.91 FastEthernet0 171.68.0.82 FastEthernet0 171.68.0.82 FastEthernet0 171.68.0.86 FastEthernet0 171.68.0.86 FastEthernet0 171.68.0.80 FastEthernet0 171.68.0.80 FastEthernet0 171.68.28.70 Serial2.31 171.68.28.70 Serial2.31 171.68.28.50 Serial2.33 171.68.28.50 Serial2.33 171.68.27.74 Serial2.36 171.68.27.74 Serial2.36 171.68.28.170 Serial0.70 171.68.28.170 Serial0.70 171.68.27.2 Serial1.51 171.68.27.2 Serial1.51 171.68.28.110 Serial3.56 171.68.28.110 Serial3.56 171.68.28.58 Serial3.102 171.68.28.58 Serial3.102

Uptime Uptime 2w1d 2w1d 2w6d 2w6d 7w0d 7w0d 7w0d 7w0d 7w0d 7w0d 22:47:11 22:47:11 22:47:22 22:47:22 22:47:07 22:47:07 1d04h 1d04h 1w4d 1w4d 1d04h 1d04h 12:53:25 12:53:25

Expires Expires 00:01:24 00:01:24 00:01:01 00:01:01 00:01:14 00:01:14 00:01:13 00:01:13 00:01:02 00:01:02 00:01:16 00:01:16 00:01:08 00:01:08 00:01:21 00:01:21 00:01:06 00:01:06 00:01:25 00:01:25 00:01:20 00:01:20 00:01:03 00:01:03

Mode Mode Dense Dense Dense Dense (DR) (DR) Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

25 25

show ip pim neighbor command output


Neighbor Address - the IP address of the PIM Neighbor Interface - the interface where the PIM Query of this neighbor was received. Uptime - the period of time that this PIM Neighbor has been active. Expires - the period of time after which this PIM Neighbor will no longer be considered as active. (Reset by the receipt of a another PIM Query.) Mode - PIM mode (Sparse, Dense, Sparse/Dense) that the PIM Neighbor is using. (DR) - Indicates that this PIM Neighbor is the Designated Router for the network.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

25

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

26 26

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

26

PIM State

Describes the state of the multicast distribution trees as understood by the router at this point in the network. Represented by entries in the multicast routing (mroute) table Used to make multicast traffic forwarding decisions Composed of (*, G) and (S, G) entries Each entry contains RPF information
Incoming (i.e. RPF) interface RPF Neighbor (upstream)

Each entry contains an Outgoing Interface List (OIL)


OIL may be NULL

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

27 27

PIM State
In general, Multicast State basically describes the multicast distribution tree as it is understood by the router at this point in the network. However to be completely correct, Multicast State describes the multicast traffic forwarding state that is used by the router to forward multicast traffic.

Multicast Routing (mroute) Table


Multicast state is stored in the multicast routing (mroute) table and which can be displayed using the show ip mroute command. Entries in the mroute table are composed of (*, G) and (S, G) entries each of which contain: RPF Information consisting of an Incoming (or RPF) interface and the IP address of the RPF (i.e. upstream) neighbor router in the direction of the source. (In the case of PIM-SM, this information in a (*, G) entry points toward the RP. PIM-SM will be discussed in a later module.) Outgoing Interface List (OIL) which contains a list of interfaces that the multicast traffic is to be forwarded. (Multicast traffic must arrive on the Incoming interface before it will be forwarded out this interfaces. If multicast traffic does not arrive on the Incoming interface, it is simply discarded.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

27

PIM-DM State Example


sj-mbone> 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 (*, 224.1.1.1), 00:00:10/00:00:00, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Dense, 00:00:10/00:00:00 Serial1, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, 224.1.1.1), 00:00:10/00:02:49, flags: T Incoming interface: Serial0, RPF nbr 198.92.1.129 Outgoing interface list: Serial1, Forward/Dense, 00:00:10/00:00:00 Serial3, Prune/Dense, 00:00:05/00:02:55

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

28 28

PIM-DM State Example


(*, G) Entry - The (*, 224.1.1.1) entry shown in sample output of the show ip mroute command is the (*, G) entry. These entries are not directly used for multicast traffic forwarding in PIM-DM. However in Cisco IOS, all (S, G) entries will always have a parent (*, G) entry and in the case of PIM -DM the OIL of these entries reflect interfaces that: Have PIM -DM neighbors or Have directly connected members or Have been manually configured to join the group. (S, G) Entry - The (128.9.160.43/32, 224.1.1.1) entry is an example of an (S, G) entry in the mroute table. This entry is used to forward any multicast traffic sent by source 128.9.160.43 to group 224.1.1.1. Notice the following: The Expires countdown timer in the first line of the (S, G) entry which shows when the entry will expire and be deleted. This entry is reset to 3 minutes whenever an (S, G) multicast packet is forwarded. The Incoming interface information is used to RPF check arriving (S, G) multicast traffic. If a packet does not arrive via this interface, the packet is discarded. The Outgoing Interface list which reflects the interfaces where (S,G) packets are to be forwarded. Note that Serial3 has been pruned and traffic is not being forwarded out this interface. Also note that the prune status of this interface will expire in 00:02:55 at which time the interface will return to Forward status. (This is how the flood and prune mechanism is accomplished.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

28

PIM-DM (*,G) State Rules


(*,G) created automatically
When 1st (S,G) for group is created
(S,G)s must always have a parent (*,G)

When a directly connected member joins the group

(*,G) reflect PIM neighbor adjacency


IIF = NULL OIL = all interfaces
with PIM-DM neighbors or with directly connected hosts or manually configured
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

29 29

PIM-DM (*,G) State Rules


All (S, G) entries must always have a parent (*, G) entry. Therfore, (*, G) entries are automatically created whenever an (S, G) entry for the group must be created. The (*, G) entry is created first and then the (S, G) entry. The reason for this will become clear shortly. PIM-DM (*, G) entries are also created as a result of a directly connected member joining the group. This can result in a (*, G) entry without a corresponding (S, G) entry if there are no sources currently sending traffic to group G. PIM -DM (*, G) entries reflect PIM neighbor/member adjacency In PIM -DM, the (*, G) entry is not used for actual traffic forwarding. Therefore, the Incoming interface information is meaningless and therefore always Null. The OIL of a PIM-DM (*, G) entry reflects PIM-DM neighbor and/or member adjacency. Therefore, any interface with a PIM-DM neighbor or a directly connected member of the group will be reflected in the OIL of the (*, G) entry. (Note: It is also possible to force the router into thinking that there is a directly connected member of the group on the interface using the ip igmp static-group <group> command.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

29

PIM-DM (S,G) State Rules


(S,G) created by multicast data arrival
Parent (*,G) created (if doesnt exist) IIF = RPF Interface in direction of source OIL = Copy of OIL from (*,G) minus IIF

Interfaces in OIL initially Forward


Go to Pruned state when Prune rcvd Forward intfc timers never expire Pruned intfc timers expire in 3 minutes
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

30 30

PIM-DM (S, G) Rules


In PIM -DM, (S, G) state is created on the fly as the result of the arrival of multicast data. When a (S, G) packet arrives at a router and a corresponding (S, G) entry does not exist, one is created as follows: If a corresponding (*, G) entry does not exist, it is created first and its Outgoing Interface list populated using the rules previously described. The RPF Information is computed for the source S. This information is stored in the (S, G) entry as the Incoming interface and the RPF neighbor (i.e. the PIM-DM neighbor in the direction of the source). The OIL of the (S, G) entry is populated with a copy of the OIL from the parent (*, G) entry less the Incoming interface. (The Incoming interface must not appear in the OIL otherwise a multicast route loop could occur.) The interfaces in the (S, G) OIL are initially placed in Forward/Dense status so that arriving (S, G) traffic (that arrives on the RPF interface) is forwarded out these interfaces. These interfaces remain in this status until a Prune message is received via the interface. At that point, the status of the interface will switch to Pruned/Dense which stops the forwarding of traffic out this interface. When an interface changes status to Pruned/Dense, the interface prune timer is started which causes the interface to switch back to Forward/Dense status after 3 minutes have lapsed.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

30

PIM-DM State Flags


D C L P T = Dense Mode = Directly Connected Host = Local (Router is member) = Pruned (All intfcs in OIL = Prune) = Forwarding via SPT

Indicates at least one packet was forwarded

J = Join SPT
Always on in (*,G) entry in PIM-DM Basically meaningless in PIM-DM

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

31 31

PIM-DM State Flags


D Flag ((*, G) entries only) Indicates the group is operating in Dense mode. (Appears only on (*, G) entries.) C Flag Indicates that there is a member of the group directly connected to the router. L Flag Indicates the router itself is a member of this group and is receiving the traffic. (This would be the case for the Auto-RP Discovery group 224.0.1.40 which all Cisco routers join automatically.) P Flag Set whenever all interfaces in the outgoing interface list of an entry are Pruned (or the list is Null). This general means that the router will send Prune messages to the RPF neighbor to try to shutoff this traffic.) T Flag ((S, G) entries only) Indicates that at least one packet was received via the SPT J Flag Always on in (*,G) entries in PIM -DM. Used by the internal code. Basically meaningless in PIM-DM.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

31

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

32 32

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

32

PIM DM Flooding
S0 S3 S1

rtr-a

S0

rtr-b
E1

PIM Dense mode interfaces are placed on the (*,G) oilist for a Multicast Group IF:
PIM neighbor heard on interface Host on this interface has joined the group Interface has been manually configured to join group.

(S,G) entries inherit a copy of the (*,G) oilist .


Minus the Incoming Interface
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

33 33

PIM DM Forwarding
If a PIM neighbor is present - dense mode assumes EVERYONE wants to receive the group so it gets flooded to that link by definition. This is accomplished as follows: The (*, G) OIL is populated with interfaces that have PIM -DM neighbors or a directly connected member of the group. (This can also be simulated via manual configuration of the interface.) When the (S, G) entry associated with the traffic flow is created, its OIL is populated with a copy of the interfaces in the (*, G)OIL less the Incoming interface. This results in arriving (S, G) traffic being initially flooded to all PIM-DM neighbors and/or directly connected members of the group. The next few slides/pages will demonstrate this process in a step by step fashion.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

33

PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

Arriving data causes rtr-a to create state

S0

rtr-b
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

34 34

Arriving data causes rtr-a to create state A parent (*, G) entry must first be created before the (S, G) entry can be created.
The (*, 224.2.127.254) entry is created and the outgoing interface list is populated with interfaces that: Have a PIM -DM neighbor or Have a directly connected member or Has manually be configured to join the group (Note: In this example, PIM-DM neighbors are assumed to be connected to rtr-a via S0 and S1.)

The (S, G) entry is then created.


The RPF information for source 128.9.160.43 is computed which results in the Incoming interface being Serial0 and an RPF neighbor of 198.92.1.129. The (S, G) Outgoing interface list (oil) is populated with a copy of the (*,G) oil minus the Incoming interface Serial0. This results in Serial1 and Serial3 being in the (S, G) oil. The status of these interfaces are initially Forward/Dense which results in the data being flooded out these interfaces. Note that the Expiration timers on the interfaces in the oilist are both 00:00:00. This means that traffic will continue to be forwarded out this interface until a prune is received. The Expiration countdown timer of the (S, G) entry indicates 00:02:49. This timer will be reset to 00:03:00 whenever an (S, G) packet is forwarded. If the counter reaches zero, the (S, G) entry will be deleted. If it is the last (S,G) entry, the (*, G) entry will also be deleted.
Copyright ? ?1998-2001, Cisco Systems, Inc.
Module3.ppt

34

PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

Packets are flooded out all interfaces in (S, G) oilist .

S0

rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

35 35

Initial Flooding
Now that the (*, G) and (S, G) entries have been created, the router begins to forward all (S, G) multicast traffic based on the (S, G) entry. Traffic arriving at rtr-b will be RPF checked against the Incoming interface, Serial0. Any (S, G) packets that do not arrive via this interface will fail the RPF check and be discarded. Traffic arriving via this interface will RPF check successfully and be forwarded based on the (S, G) OIL. At this point in the example, that status of both Serial1 and Serial3 in the OIL are both Forward/Dense. This causes arriving (S, G) traffic (that RPF checks) to initially be flooded out these two interfaces.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

35

PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

Arriving data causes rtr-b to create state

S0

rtr-b
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: PT PT Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.2.31 198.92.2.31 Outgoing Outgoing interface interface list: list: Null Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

36 36

Arriving data causes rtr-b to create state A parent (*, G) entry must first be created before the (S, G) entry can be created.
The (*, 224.2.127.254) entry is created and the outgoing interface list is populated with interfaces that: Have a PIM -DM neighbor or Have a directly connected member or Has manually be configured to join the group This results in only Serial0 being places in the (*,G) oil.

The (S, G) entry is then created.


The RPF information for source 128.9.160.43 is computed which results in the Incoming interface being Serial0 and an RPF neighbor of 198.92.2.31. The (S, G) Outgoing interface list (oil) is populated with a copy of the (*,G) oil minus the Incoming interface Serial0. The removal of the Incoming interface results in the (S, G) oil being Null. The P flag is set on the (S, G) entry which indicates that rtr-b will send a Prune messages to rtr-a. (See the section on Pruning.) The Expires countdown timer of the (S, G) entry indicates 00:02:48. This timer would normally be reset to 00:03:00 whenever an (S, G) packet is forwarded. However, since the (S, G) entry has a Null oil, the counter will reach zero in 2 minutes and 48 seconds, at which time the (S, G) entry will be deleted. If it is the last (S,G) entry, the (*, G) entry will be deleted. (The arrival of another (S, G) packet from rtr-a will recreate the state as described above.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

36

Potential PIM-DM Route Loop


Normal Steady-State Traffic Flow

Source
Interface previously Pruned by Assert Process

RPF Interface

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

37 37

Potential PIM-DM Route Loops


The non-deterministic behavior of PIM -DM along with its flood-and-prune mechanism can sometimes result in serious network outages including blackholes and multicast route loops. The network in the above example is a simplified version of a frequently used network design whereby multiple routers are used to provide redundancy in the network. Under normal steady -state conditions, traffic flows from the source via the RPF interfaces as shown. Note that the routers have performed the Assert process and one interface on one router is in the pruned state.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

37

Potential PIM-DM Route Loop


Interface Fails X
Source
This Router converges first

RPF Interface

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

38 38

Potential PIM-DM Route Loops


Now lets assume that the forwarding interface of the first-hop router fails as shown above. Lets also assume that the unicast routing of router on the left converges first and PIM computes the new RPF interface as shown.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

38

Potential PIM-DM Route Loop


New Traffic Flow X
Source
But wait . . . This Router still hasnt converged yet

Multicast Route Loop ! !


RPF Interface

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

39 39

Potential PIM-DM Route Loops


Unfortunately, the middle router has not yet converged and is still forwarding multicast traffic using the old RPF interface. At this point, a multicast route loop exists in the network due to the transient condition of the two routers having opposite RPF interfaces. During the time that this route loop exists, virtually all of the bandwidth on the network segments can be consumed. This situation will continue until the router in the middle of the picture finally converges and the new correct RPF interface is calculated. Unfortunately, if the router needs some bandwidth to complete this convergence (as in the case when EIGRP goes active), then this condition will never be resolved!

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

39

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

40 40

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

40

PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

Initial Flooding State in rtr-a

S0

rtr-b
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

41 41

Initial Flooding State in rtr-a


Let us again review the state in the router that resulted in the initial flooding of (S, G) traffic. Pay particular attention to the following: Both an (*, G) and (S, G) entry exist. In PIM DM, (*, G) entries are created automatically as soon as the first packet (from any source) arrives for group G or when a locally connected host has joined the group via IGMP. Both Serial1 and Serial3 are in the Outgoing interface list (oilist) for the (S, G) entry. This is because there is a PIM Neighbor on these interfaces in this example. The Expires times on the interfaces in the oilist are both 00:00:00. This is because in PIM DM, only pruned interfaces timeout since we are using a flood and prune model.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

41

PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) 2 Prune S0 S3 S1

rtr-a

E1

1 2 3

rtr-a initially floods (S, G) traffic out all interfaces in oilist. rtr-b is a leaf node w/o receivers. Sends Prune for (S,G). rtr-a Prunes interface for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.

rtr-b

Module3. ppt

8/10/2001 11:41 AM

42 42

Step 1
As a result of the initial flooding state (shown in the previous slide), rtr-a is flooding (S, G) traffic out interfaces Serial3 and Serial 1.

Step 2
rtr-b is a leaf node without any downstream PIM-DM neighbors or directly connected members of the group. This is reflected in rtr-bs (S, G) entry (shown in the previous slide) by the Null OIL and the corresponding P flag being set. As a result of the above, rtr-b sends an (S, G) Prune message to rtr-a to shutoff the flow of unwanted traffic.

Step 3
rtr-a responds by pruning interface Serial3. (This is reflected in the (S, G) state shown in the next slide.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

42

PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

State in rtr-a after Pruning

S0

rtr-b
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing interface list: Outgoing interface list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial3, Serial3, Prune/Dense, Prune/Dense, 00:00:12/00:02:56 00:00:12/00:02:56
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

43 43

State in rtr-a after Pruning


Pay particular attention to the following: Serial3 in the Outgoing interface list (oilist) for the (S, G) entry is now in the Pruned state. The Expires time on interface Serial3 now shows 00:02:56 which indicates that the Prune state will expire in 2 minutes and 56 seconds. At that time, the interface will return to the Forward state and (S, G) traffic will once again be flooded to rtr-b. When this happens, rtr-b will have to send another Prune to rtr-a to shutoff the unwanted (S, G) traffic. This periodic flood and prune behavior is normal for PIM Dense mode.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

43

PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1

rtr-a

State in rtr-b before/after Pruning

S0

rtr-b
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: PT PT Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.2.31 198.92.2.31 Outgoing Outgoing interface interface list: list: Null Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

44 44

State in rtr-b after Pruning


Pay particular attention to the following: The Outgoing interface list (oilist) for the (S, G) entry is still Null and the P flag is still set. This indicates that rtr-b will send (S, G) Prunes out the Incoming interface to rtr-a which is the RPF neighbor in the direction of the source.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

44

PIM Prune Delay on Multiaccess Networks


rtr-a
S0 (S,G) Packets E0 1 E0 4 S1
Ill wait 3 secs to see 2 if someone else wants (S,G) before I Prune Interface E0.

Prune

E0

Join 3

rtr-b
E1

rtr-c
E1

Receiver

1 2 3 4

rtr-b is a leaf node w/o receivers. Sends Prune for (S,G). rtr-a schedules a Prune for (S,G) to occur in 3 seconds. rtr-c hears Prune from rtr-b. Overrides with a Join. rtr-a hears Join and cancels Prune for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.

Module3. ppt

8/10/2001 11:41 AM

45 45

PIM Prune Delay on Multi-access Networks


rtr-a schedules a prune when asked but doesnt do it right away because it received the (S, G) Prune on a multi-access interface. This gives any other router on the LAN the chance to override the (S, G) Prune if they still need the (S, G) traffic. In the above example, this process occurs as follows: rtr-b is a leaf node with no downstream neighbors or directly connected members so it sends an (S, G) prune. rtr-a receives this (S, G) Prune and schedules the prune of interface Ethernet0 to occur in 3 seconds. rtr-c overhears to (S, G) Prune sent to rtr-a. (It overheard this because all PIM control messages are multicast on the local wire.) Because rtr-c has a directly connected member, it overrides the (S,G) Prune by sending an (S, G) Join to rtr-a. When rtr-a hears this (S, G) Join, it cancels the Prune scheduled for interface Ethernet0. If there was local igmp state for this group on rtr-a (i.e. there was a directly connected member on the LAN) and neither rtr-b and rtr-c had downstream members (and therefore did not override the (S, G) Prune), the (S, G) Prune would be ignored by rtr-a.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

45

PIM Prune Delay on Multiaccess Networks


Watch out for the ripple affect of this Delay!!!
Source

X X
Prune 3 sec delay 3 sec delay Prune

X X
Prune 3 sec delay 3 sec delay Prune

Source begins sending traffic which is flooded everywhere. Leaf router has no receivers; sends prune which ripples up the tree. Total time to prune back to source = 12 seconds! Process repeats 3 minutes later when prunes timeout!
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

46 46

Accumulative Affect of Prune Delays


The 3 second prune delay on multi-access networks can be accumulative and should be taken into account during PIM -DM network design. In the above example, a source is transmitting to a multicast group for which there are no members. The normal prune process is initiated by the router on the far right. However, due to the normal 3 second Prune Delay on multi-access links, the upstream router does not prune its interface for three seconds. When this does happen, the upstream router itself then triggers a Prune to its upstream router. Because this router is also connected via a multi-access network, this prune will also be delayed by three seconds. This process continues adnauseum until it reaches the first hop router directly connected to the source. In this example, a total of 12 seconds was required to completely shutoff the flow of unwanted traffic. Unfortunately, this process is repeated three minutes later when the prunes timeout and re-flooding occurs..

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

46

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

47 47

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

47

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

rtr-b
E1

rtr-c
E1

Beginning State
rtr-b and rtr-c have previously Pruned (S,G) traffic. rtr-a is still forwarding traffic downstream via S1.

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

48 48

PIM DM Grafting Example


Initially, rtr-b and rtr-c have previously Pruned (S, G) traffic. rtr-a is still forwarding traffic downstream via S1 which, for this example, well assume hasnt been pruned.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

48

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

Beginning State in rtr-a

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Ethernet0, Ethernet0, Prune/Dense, Prune/Dense, 00:01:29/00:01:30 00:01:29/00:01:30 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

49 49

Beginning State in rtr-a


Pay particular attention to the following: Ethernet0 in the Outgoing interface list (oilist) for the (S, G) entry is in the Pruned state.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

49

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null

Beginning State in rtr-b


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

50 50

Beginning State in rtr-b


Pay particular attention to the following: The Incoming interface for the (S, G) entry is Ethernet0. The Outgoing interface list for the (S, G) entry is Null. The P flag is set in the (S, G) entry which indicates the entry is in the Pruned state.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

50

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null

Beginning State in rtr-c


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

51 51

Beginning State in rtr-c


Pay particular attention to the following: The Incoming interface for the (S, G) entry is Ethernet0. The Outgoing interface list for the (S, G) entry is Null. The P flag is set in the (S, G) entry which indicates the entry is in the Pruned state.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

51

PIM DM Grafting
S0 (S,G) Packets 3 PIM Graft-ACK E0 2 PIM Graft E1
IGMP Join Rcvr A

S1 E0

rtr-a
4 E0

rtr-b

rtr-c
E1 1

1 2 3 4

Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends PIM Graft for Group (S,G). rtr-a acknowledges with a PIM Graft-Ack. rtr-a begins forwarding traffic for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.

Module3. ppt

8/10/2001 11:41 AM

52 52

PIM DM Grafting Example (cont.)


1) Rcvr A wishes to receive group G traffic. Therefore, it sends an IGMP Host Membership Report to rtr-b. rtr-b receives the IGMP Host Membership Report and creates IGMP Group state on the interface toward Rcvr A. 2) rtr-b already has (*, G) and (S, G) state. However, the interface towards Rcvr A is in the Prune state. Therefore rtr-b sends a PIM Graft to its upstream neighbor rtr-a, in the direction of the source. 3) rtr-a receives the Graft and acknowledges with a Graft -Ack. 4) rtr-a begins forwarding traffic for (S, G).

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

52

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

State in rtr-a after Grafting

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:00:25/00:00:00 00:00:25/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

53 53

State in rtr-a after Grafting


Pay particular attention to the following: Both Ethernet0 and Serial1 in the Outgoing interface list (oilist) for the (S, G) entry are now in the Forward state.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

53

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:00:00, 00:04:10/00:00:00, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet1, Ethernet1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: C CT T Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Outgoing interface list: Ethernet1, Ethernet1, Forward/Dense, Forward/Dense, 00:00:26/00:00:00 00:00:26/00:00:00

State in rtr-b after Grafting


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

54 54

State in rtr-b after Grafting


Pay particular attention to the following: Ethernet1 is now in the (S, G) Outgoing interface list and is in the Forward state. The P flag has been cleared in the (S, G) entry The T flag is set indicating that traffic is successfully flowing down the Shortest-Path Tree.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

54

PIM DM Grafting
S0 (S,G) Packets S1 E0

rtr-a

E0

E0

rtr-b
E1

rtr-c
E1

(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null

State in rtr-c after Grafting


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

55 55

State in rtr-c after Grafting


Notice there has been no change in the state: The Incoming interface for the (S, G) entry is Ethernet0. The Outgoing interface list for the (S, G) entry is Null. The P flag is set in the (S, G) entry which indicates the entry is in the Pruned state. The obvious question at this point is, Will rtr-c begin sending (S, G) Prunes in an attempt to shutoff this unwanted traffic? The answer is no because ratelimited prunes are only sent on P2P interfaces. This implies the following: When (S, G) traffic is received on the RPF interface which is a non-P2P link (in this case an Ethernet) and the OIL is Null, an (S, G) Prune message is sent only once at the time the (S, G) entry transitions to a Null OIL. This implies that when the (S, G) entry expires and is deleted, the next arriving (S, G) packet will recreate the (S, G) entry and another single (S, G) Prune will triggered by rtr-c which will be overriden by an (S, G) Join by rtrb. As long as the source remains active, this periodic Prune and Join override will occur every three minutes.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

55

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

56 56

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

56

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check)

S0 A E0 .1 192.168.1.0/24 1

S0 B E0 .2

C 1

Receiver

Routers A & B receive packet on an interface in their oilist !!


Only one router should continue sending to avoid duplicate packets.

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

57 57

PIM Assert Mechanism


The PIM Assert mechanism is used to shutoff duplicate flows onto the same multi-access network. Routers detect this condition when they receive an (S, G) packet via a multiaccess interface that it is in the (S, G) OIL. This is explained in the example presented in the next few slides.

Step 1
Routers A & B receive both receive the same (S, G) traffic via their proper RPF interfaces (Serial0) and forward the packet onto the common Ethernet segment. Routers A & B therefore will receive an (S, G) packet via a multi-access interface that is in the Outgoing Interface list of their (S, G) entry. This triggers the Assert mechanism.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

57

PIM Assert Mechanism

Loser S0 Assert <distance, metric> 192.168.1.0/24 2 A E0 .1 Pruned S0

Winner B E0 .2

2 Assert <distance, metric>

X
C

Receiver

Routers send PIM Assert messages


Compare distance and metric values Router with best route to source wins If metric & distance equal, highest IP adr wins Losing router stops sending (prunes interface)

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

58 58

Step 2
Routers A & B both send PIM Assert messages that contain their Administrative Distance and route Metric back to the source. Note: The Administrative Distance and route Metric is treated as a single combined numeric value where the Administrative Distance is the high-order part of the numeric value. Therefore, even though different routing protocols use different metrics, the lower Administrative Distance will take precedence. Each router compares the received Administrative Distance/Metric value with its own and the router with the best (lowest) value wins the Assert. In case of a tie, the highest IP address is used as the tie breaker. The losing router will Prune its interface just as if it had received a Prune on this interface. Note: This prune will timeout in 3 minutes and cause the router to begin forwarding on this interface again. This triggers another Assert process. By the same token, if the winning router were to crash, the loser would take over the job of forwarding onto this LAN segment after its prune timed out.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

58

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check) Loser S0 A E0 .1 192.168.1.0/24 S0 B E0 .2 Join 4 Prune 3 Winner

If there are no directly connected members on the interface, the winning router sends a Prune and waits 3 seconds for a Join override. This will shutoff traffic if it is not needed somewhere downstream. Router C does need traffic. Sends join to override.
1998 2001, Cisco Systems, Inc. All rights reserved.

X
C

Receiver

4
Module3. ppt

8/10/2001 11:41 AM

59 59

Step 3
In the case where there are no directly connected members on the LAN segment (as is the case in our example), the winning router will send an (S,G) Prune message and schedule its interface to be pruned after the normal 3 second prune delay. This mechanism allows traffic to be shutoff if there are no members of the group further downstream of the LAN segment. (Which is not the case in the figure above.

Step 4
In this example, downstream router C does need the traffic (it has a directly connected receiver) so it responds to the (S, G) Prune sent by the winning router by sending an overriding (S, G) Join. This cancels the scheduled Prune in Router B and thereby continues the flow of (S, G) traffic onto the transit LAN.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

59

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check) Loser S0 A E0 .1 192.168.1.0/24 5 S0 B E0 .2 Pruned 6 Winner

5 6

If router C doesnt need the traffic, no Join override is sent. Router B prunes its interface after 3 second prune delay.
This stops the flow of traffic onto the transit LAN.
1998 2001, Cisco Systems, Inc. All rights reserved.

X
C

X
60 60

Module3. ppt

8/10/2001 11:41 AM

Step 5
On the other hand, if the none of the downstream router(s) need the traffic (as is the case in the example shown above), no (S, G) Join is sent to override the (S, G) Prune sent by the winning router, Router B.

Step 6
After the normal 3 second Prune delay expires and Router B has not received an (S, G) Join to override the prune, it goes ahead and Prunes its interface. This shuts off the flow of traffic onto the transit LAN segment. Note: The prune of Router Bs Ethernet interface will timeout after 3 minutes just as if it had received an (S, G) prune on this interface. This means that traffic will start to flow via this interface after 3 minutes which will trigger Router A to start the Assert process all over again.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

60

PIM Assert Mechanism


Downstream routers must listen for the assert winner to know which router to send prunes and grafts
RPF Neighbor A
.1 E0 S0 S0

B
E0 .2
198.92.2.0/24

Routing Protocol Boundary

State in Router C before Assert

(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

61 61

Downstream routers on the Assert LAN


It is important for downstream routers that are on the Assert LAN to note who wins the Assert process. This is because it must address any PIM (S,G) control messages (Joins, Prunes, Grafts) to the RPF neighbor (i.e. upstream neighbor) in the direction of the source. In this example, assume that Router A has a better metric to the source. However, because there is a routing protocol boundary between Router C and the other two routers, Router Cs unicast routing table does not know that Router A has better metric to the source. As a result, the unicast routing table in Router C indicates that the best route back to the source is via Router B. This is reflected by the RPF nbr field of the (S, G) entry.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

61

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check)

RPF Neighbor Assert Winner


Assert .1

A
E0

S0

S0

B
E0 .2

Assert Loser
Assert

Routing Protocol Boundary

198.92.2.0/24

C
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

62 62

Downstream routers on the Assert LAN (cont.)


When traffic begins to flow, it triggers Routers A & B to send Assert messages. Because Router A has a better (lower) metric to the source than Router B and therefore Router A wins the assert.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

62

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check)

RPF Neighbor Assert Winner


.1

A
E0

S0

S0

B
E0 .2

Assert Loser
Pruned

X
198.92.2.0/24

Routing Protocol Boundary

C
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

63 63

Downstream routers on the Assert LAN (cont.)


Because Router B is the Assert Loser, it Prunes its interface. Traffic now flows through Router A, the Assert Winner.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

63

PIM Assert Mechanism


Incoming Multicast Packet
(Successful RPF Check)

RPF Neighbor Assert Winner


.1

A
E0

S0

S0

B
E0 .2

Assert Loser

Routing Protocol Boundary

198.92.2.0/24

State in Router C after Assert

Assert Winner

(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.1 Outgoing interface list: Null

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

64 64

Downstream routers on the Assert LAN (cont.)


Because Router C has overheard the Assert process (because PIM control messages are multicast onto the local link), it was able to determine who has won the Assert process. Router C now updates its RPF nbr information to reflect that Router A is now the correct upstream neighbor in the direction of the source. This will result in any (S, G) PIM control traffic (Joins, Prunes, Grafts) being sent with the IP address of Router A in the Upstream Neighbor Address field of the PIM control message. If Router C didnt update its RPF nbr information and continued to send PIM control traffic (Joins, Prunes, Grafts) to Router B (the old RPF nbr), it would not be able to properly control the flow of multicast traffic since the control messages would be going to the wrong upstream neighbor.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

64

PIM-DM Assert Problem

Initial Flow
Duplicate Traffic

Receiver

Receiver

Multicast Packets

Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

65 65

PIM-DM Assert Problem


While the PIM Assert mechanism is effective in pruning off duplicate traffic, it is not without its weaknesses. Consider the above example where duplicate traffic is flowing onto a LAN segment.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

65

PIM-DM Assert Problem

Sending Asserts
Loser

Receiver

Receiver

Winner

Multicast Packets Assert Messages Source


Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

66 66

PIM-DM Assert Problem


The normal PIM Assert mechanism takes place and the two routers exchange routing metrics to determine which one has the best route to the source. In this case, the bottom router has the best metric and is the Assert Winner.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

66

PIM-DM Assert Problem

Assert Loser Prunes Interface


Loser

Receiver

Receiver

Winner

Multicast Packets

Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

67 67

PIM-DM Assert Problem


The normal PIM Assert mechanism takes place and the Assert Winner continues forwarding while the Assert Loser prunes its interface and starts its prune timer.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

67

PIM-DM Assert Problem

Assert Winner Fails


Traffic flow is cutoff until Prune times out on Assert Loser. Loser

Receiver

Receiver

X
Winner Multicast Packets Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

68 68

PIM-DM Assert Problem


Lets now assume that the Assert Winner fails immediately after winning the Assert process. Unfortunately, the Assert Loser has no way of knowing that the Assert Winner has failed and will wait 3 minutes before timing out its pruned interface. This results in a 3 minute (worst-case) loss of traffic.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

68

PIM DM Concepts

PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

69 69

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

69

PIM DM State Maintenance


State is maintained by the flood and prune behavior of Dense mode.
Received Multicast packets reset (S,G) entry expiration timers. When (S, G) entry expiration timers count down to zero, the entry is deleted.

Interface prune state times out every 3 minutes causing periodic reflooding and pruning.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

70 70

PIM DM State Maintenance


In PIM DM, all (S, G) entries have an expiration countdown timer which is reset to 3 minutes by the receipt of an (S, G) packet received via the Shortest-Path Tree (SPT). If no further packets are received from the source, this expiration timer goes to zero and the (S, G) entry is deleted. When a Prune message is received in PIM Dense mode, the interface on which the Prune was received is marked as Prune/Dense and a prune countdown timer is set to 3 minutes. When this timer expires, the interface is set back to Forward/Dense and traffic is again flooded out the interface. The downstream router will again send another (S, G) Prune to stop the unwanted traffic; therfore the Flood and Prune behaviour occurs every 3 minutes.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

70

PIM Dense Mode Review


Source Link Data Control A B G C D F H E Receiver 1 I Receiver 2

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

71 71

PIM Dense Mode Review


The following slides will review all the major concepts previously present in a sample network situation.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

71

PIM Dense Mode Review


Source Initial Flood of Data and Creation of State A B G C D F H E Receiver 1 I Receiver 2

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

72 72

PIM Dense Mode Review (cont.)


Source starts sending and the (S,G) gets initailly flooded everywhere

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

72

PIM Dense Mode Review


Source Prune to Non-RPF Neighbor

A Prune C

B G D F H E I Receiver 2

Receiver 1

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

73 73

PIM Dense Mode Review (cont.)


The link between B & C is not Cs RPF interface for this group so a prune is immediately sent to B and this link is removed off of the tree at B

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

73

PIM Dense Mode Review


Source C and D Assert to Determine Forwarder for the LAN, C Wins A B G C Asserts H E Receiver 1 I Receiver 2 D F

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

74 74

PIM Dense Mode Review (cont.)


C & D are redundant forwarders for their common Ethernet - they assert - C wins (assume a better metric to the source or that C has a higher IP address if the metrics are equal)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

74

PIM Dense Mode Review


Source I Gets Pruned

B G

D Prune E I

F H

Receiver 1

Receiver 2

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

75 75

PIM Dense Mode Review (cont.)


I prunes off - it has no need to receive the group

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

75

PIM Dense Mode Review


Source Es Prune is Ignored

B G

C Prune E Receiver 1

F H I Receiver 2

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

76 76

PIM Dense Mode Review (cont.)


E prunes but it is ignored since C knows there is a locally attached host via IGMP state

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

76

PIM Dense Mode Review


Source

Gs Prune is Overridden A B Prune G C D F Join Override H E Receiver 1 I Receiver 2

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

77 77

PIM Dense Mode Review (cont.)


G prunes since it doesnt need the group H overrides the prune since it does need it - F continues to forward on this link G will continue to receive the group input on the common Ethernet but since its oif is NULL, the packets are fast switched to the bit bucket

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

77

PIM Dense Mode Review


Source New Receiver, I Sends Graft

B G

D Graft E I

F H

Receiver 1 Receiver 3
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Receiver 2

8/10/2001 11:41 AM

78 78

PIM Dense Mode Review (cont.)


Assume a new receiver (#3) comes on behnd rtr I I grafts onto E E already had state for this group sicne it was still being received on the C,D,E Ethernet so it starts sending the group to I

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

78

PIM Dense Mode Review


Source I is Grafted back onto tree

B G

F H

E Receiver 1

I Receiver 2 Receiver 3

Module3. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

79 79

PIM Dense Mode Review (cont.)


E already had state for this group sicne it was still being received on the C,D,E Ethernet so it starts sending the group to I Final state given all events in the network

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

79

Configuring PIM Dense Mode


ip multicastmulticast- routing S0 E1 E0 interface Ethernet 0 ip address 1.1.1.1 255.255.0.0 ip pim dense dense- mode interface Ethernet 1 ip address 2.2.2.2 255.255.0.0 ip pim dense dense- mode interface Serial 0 ip address 192.1.1.1 255.255.255.252 ip pim dense dense- mode

Simple to configure
One global command One command per interface
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 11:41 AM

80 80

Configuring PIM Dense Mode


Configuring PIM Dense Mode multicasting is very simple. The following commands are the only configuration commands necessary: Add the ip multicast-routing global command to the configuration. Add the ip pim dense-mode interface command to each interface in the router configuration to enable ip multicasting using PIM Dense mode. (Warning: Use caution if you do not add the above command to all interfaces in the router. Problems can occur if some interfaces in the router are not running multicast. This is because the RPF check mechanism uses the Unicast route table to compute the RPF interface. If the RPF interface maps to an interface that is not running multicasting RPF Failures can occur.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

80

Module2. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

81

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module3.ppt

81

Basic Multicast Debugging


Module 4

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

Module Objectives

Introduction to IOS Command Line Interface (CLI) tools Understand usage and key information fields for IOS CLI tools in troubleshooting and monitoring the router and network Develop a Strategy for debugging multicast networks

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

Module Agenda

Router Command Review Debugging Strategies

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

Router Command Review

Show commands Debug commands Other useful commands

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip igmp groups

R4#show R4#show ip ip igmp igmp group group IGMP IGMP Connected Connected Group Group Membership Membership Group Address Interface Group Address Interface 224.1.1.1 Ethernet1 224.1.1.1 Ethernet1 224.0.1.40 Ethernet0 224.0.1.40 Ethernet0

Uptime Uptime 3d16h 3d16h 4d15h 4d15h

Expires eporter Expires Last Last RR eporter 00:01:59 .7.2 00:01:59 172.16 172.16 .7.2 never 172.16 .6.2 never 172.16 .6.2

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Uptime - shows how long there has been membership for the listed group on that interface Expires - shows when membership interest will end - IGMP reports from client members of this group are what keep this timer from expiring - you should see this value reset and not timeout as long as there are members present. When this timer expires - the multicast routing protocol is notified to stop delivery of that group onto this interface Only the last IGMP reporter is listed - this is due to report suppression

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip igmp interface


R4#show R4#show ip ip igmp igmp interface interface Ethernet1 Ethernet1 is is up, up, line line protocol protocol is is up up Internet address Internet address is is 172.16.7.1, 172.16.7.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current IGMP version is 2 Current IGMP version is 2 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 60 60 seconds seconds IGMP querier timeout IGMP querier timeout is is 120 120 seconds seconds IGMP IGMP max max query query response response time time is is 10 10 seconds seconds Inbound Inbound IGMP IGMP access access group group is is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 172.16.7.1 172.16.7.1 (this (this system) system) IGMP IGMP querying querying router router is is 172.16.7.1 172.16.7.1 (this (this system) system) No multicast groups joined No multicast groups joined

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

This is the command to verify IGMP and CGMP are enabled or disabled on the interface IGMP version can be verified with this command - this is important if you have a mixed environment of multicast routing protocols running or other routers that support different versions of IGMP - some IGMP configuration may be required IGMP timers can be verified here for tuning purposes The multicast designated router (DR) and IGMP querier for this link can also be determined with this command

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip pim neighbor

R6#show R6#show ip ip pim pim neighbor neighbor PIM PIM Neighbor Neighbor Table Table Neighbor Address Neighbor Address Interface Interface 172.16.10.2 Serial0 172.16.10.2 Serial0 172.16.11.2 Serial1 172.16.11.2 Serial1 172.16.9.1 Ethernet0 172.16.9.1 Ethernet0

Uptime Uptime 4d15h 4d15h 4d15h 4d15h 4d15h 4d15h

Expires Expires 00:01:19 00:01:19 00:01:00 00:01:00 00:01:00 00:01:00

Mode Mode Dense Dense Dense Dense Dense Dense

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Uptime - indicates how long the neighbor adjacency has existed Expires - indicates when the adjacency will timeout and be removed PIM hellos maintain this adjacency Mode - indicates what mode the interface is running in

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip pim interface

R6#show R6#show ip ip pim pim interface interface Address Interface Address Interface 172.16.10.1 172.16.10.1 172.16.11.1 172.16.11.1 172.16.9.2 172.16.9.2 Serial0 Serial0 Serial1 Serial1 Ethernet0 Ethernet0

Mode Mode Dense Dense Dense Dense Dense Dense

Nbr DR Nbr Query Query DR Count Count Intvl Intvl 11 30 0. 0.0.0 30 0. 0.0.0 11 30 0. 0.0.0 30 0. 0.0.0 11 30 17 2.16.9.2 30 17 2.16.9.2

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Nbr Count = number of neighbors on this link DR = 0.0.0.0 in this example because p2p links do not have DRs

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip rpf
R4#show R4#show ip ip rpf rpf 172.16.8.1 172.16.8.1 RPF RPF information information for for R1 R1 (172.16.8.1) (172.16.8.1) RPF RPF interface: interface: Ethernet0 Ethernet0 RPF RPF neighbor: neighbor: R3 R3 (172.16.6.1) (172.16.6.1) RPF RPF route/mask: route/mask: 172.16.8.0/255.255.255.0 172.16.8.0/255.255.255.0 RPF type: unicast RPF type: unicast R4#sh R4#sh ip ip rpf rpf 172.16.12.2 172.16.12.2 RPF RPF information information for for Source1 Source1 (172.16.12.2) (172.16.12.2) RPF interface: RPF interface: Ethernet0 Ethernet0 RPF neighbor: R6 (172.16.11.1) RPF neighbor: R6 (172.16.11.1) RPF RPF route/mask: route/mask: 172.16.12.0/255.255.255.0 172.16.12.0/255.255.255.0 RPF RPF type: type: unicast unicast

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

Top example is obtaining RPF information for the RP (on R1) The RPF interface is the interface used to reach the target address (The RP itself in this example) Also shown is the RPF neighbor on the RPF interface and the route and mask used to reach the target address The second example is the RPF information for the source of the multicast group

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

show ip route
R4#show R4#show ip ip route route Gateway Gateway of of last last resort resort is is not not set set DD DD DD DD CC DD DD DD 172.16.0.0/24 ,, 77 subnets 172.16.0.0/24 is is subnetted subnetted subnets 172.16.2.0 172.16.2.0 [90/2354611] [90/2354611] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.3.0 [90/2354611] via 172.16.3.0 [90/2354611] via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.4.0 172.16.4.0 [90/2221056] [90/2221056] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.5.0 172.16.5.0 [90/2221056] [90/2221056] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.6.0 172.16.6.0 [90/2281542] [90/2281542] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.10.0 00 172.16.10.0 [90/2281542] [90/2281542] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet Ethernet 172.16.8.0 [90/2221056] via 172.16.6.1, 4d15h, Ethernet0 172.16.8.0 [90/2221056] via 172.16.6.1, 4d15h, Ethernet0 192.169.1.0/24 192.169.1.0/24 is is subnetted, subnetted, 11 subnets subnets 192.169.1.0 00 192.169.1.0 [90/2349056] [90/2349056] via via 172.16.6.1, 172.16.6.1, 3d15h, 3d15h, Ethernet Ethernet

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

10 10

This slide for reference only for following slides - this table taken from R4 Recall that multicast forwarding decisions are made based on the unicast routing table - make sure you understand the UNICAST topology and stability before looking at MULTICAST issues

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

10

show ip mroute summary

R6#show R6#show ip ip mroute mroute summary summary IP IP Multicast Multicast Routing Routing Table Table Flags: Flags: DD -- Dense, Dense, SS -- Sparse, Sparse, CC -- Connected, Connected, LL -- Local, Local, PP -- Pruned Pruned RR -- RP-bit RP-bit set, set, FF -- Register Register flag, flag, TT -- SPT-bit SPT-bit set, set, JJ -- Join Join SPT SPT Timers: Timers: Uptime/Expires Uptime/Expires Interface Interface state: state: Interface, Interface, Next-Hop, Next-Hop, State/Mode State/Mode (*, (*, 224.1.1.1), 224.1.1.1), 00:01:47/00:02:55, 00:01:47/00:02:55, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DD (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), 00:01:47/00:02:54, 00:01:47/00:02:54, flags: flags: CT CT (*, (*, 224.0.1.40), 224.0.1.40), 3d16h/00:00:00, 3d16h/00:00:00, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DCL DCL

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

11 11

A summarized version of the multicast routing table

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

11

show ip mroute
barrnet -gw>show barrnet -gw>show ip ip mroute mroute IP IP Multicast Multicast Routing Routing Table Table Flags: D Dense, S Flags: D - Dense, S -- Sparse, Sparse, CC -- Connected, Connected, LL -- Local, Local, PP -- Pruned Pruned RR -- RP-bit set, RP-bit set, FF -- Register Register flag, flag, TT -- SPT-bit SPT-bit set, set, JJ -- Join Join SPT SPT Timers: Uptime/Expires Timers: Uptime/Expires Interface state: Interface, Next-Hop, State/Mode Interface state: Interface, Next-Hop, State/Mode (*, (*, 224.2.130.100), 224.2.130.100), 00:18:53/00:02:59, 00:18:53/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DD Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Fddi1/0, Fddi1/0, Forward/Dense, Forward/Dense, 00:09:20/00:02:38 00:09:20/00:02:38 Hssi3/0, Hssi3/0, Forward/Dense, Forward/Dense, 00:18:53/00:00:00 00:18:53/00:00:00 (208.197.169.209/32, (208.197.169.209/32, 224.2.130.100), 224.2.130.100), 00:18:53/00:02:27, 00:18:53/00:02:27, flags: flags: TT Incoming Incoming interface: interface: Hssi3/0, Hssi3/0, RPF RPF nbr nbr 131.119.26.9 131.119.26.9 Outgoing Outgoing interface interface list: list: Fddi1/0, Fddi1/0, Forward/Dense, Forward/Dense, 00:16:16/00:02:38 00:16:16/00:02:38 (*, 239.100.111.224), (*, 239.100.111.224), 05:35:08/00:02:58, 05:35:08/00:02:58, RP RP 171.69.10.13, 171.69.10.13, flags: flags: DP DP Incoming interface: Null, RPF Incoming interface: Null, RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Null Outgoing interface list: Null

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

12 12

Partial output taken from a production router in Ciscos network for more interesting output This is a generic multicast routing table Note the:
(*,G) and (S,G) entries incoming interface outgoing interface list (OIF) RP (if any) Flags times - how long the entry has been in the table and when it will expire

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

12

show ip mroute active


barrnet -gw>show barrnet -gw>show ip ip mroute mroute active active Active Active IP IP Multicast Multicast Sources Sources -- sending sending >= >= 44 kbps kbps Group: Group: 224.2.154.118, 224.2.154.118, Radio Radio Bandit Bandit Source: pilsnet .sunet.se) Source: 192.36.125.68 192.36.125.68 (falcon. (falcon. pilsnet .sunet.se) Rate: 11 pps/30 kbps(1sec), Rate: 11 pps/30 kbps(1sec), 30 30 kbps(last kbps(last 33 33 secs), secs), 23 23 kbps(life kbps(life avg) avg) Group: Group: 224.2.246.13, 224.2.246.13, UO UO Presents Presents KWAX KWAX Classical Classical Radio Radio Source: Source: 128.223.83.204 128.223.83.204 (d83-204.uoregon.edu) (d83-204.uoregon.edu) Rate: 24 pps/69 kbps(1sec), 72 kbps(last 2 secs), )) Rate: 24 pps/69 kbps(1sec), 72 kbps(last 2 secs), 70 70 kbps(life kbps(life avg avg Group: Group: 224.2.180.115, 224.2.180.115, ANL ANL TelePresence TelePresence Microscopy Microscopy Site Site Source: .anl.gov )) Source: 146.139.72.5 146.139.72.5 (aem005.amc (aem005.amc .anl.gov Rate: /5 ), )) Rate: 11 pps pps /5 kbps(1sec), kbps(1sec), 99 kbps(last kbps(last 52 52 secs secs ), 12 12 kbps(life kbps(life avg avg ... ...

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

13 13

Shows all active groups with an aggregate bandwidth greater than the specified kbps (4kbps is the default) Listed in each entry is:
group address session name source address and domain name averaged pps and kbps rates for this flow

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

13

show ip mroute count


sj-mbone> sj-mbone> show show ip ip mroute mroute count count IP IP Multicast Multicast Statistics Statistics 1460 routes using 471528 bytes 1460 routes using 471528 bytes of of memory memory 404 404 groups, groups, 2.61 2.61 average average sources sources per per group group Forwarding Counts: Pkt Count/Pkts per Avg Forwarding Counts: Pkt Count/Pkts per second/ second/ Avg Pkt Pkt Size/Kilobits Size/Kilobits per per second second Other -limit Other counts: counts: Total/RPF Total/RPF failed/Other failed/Other drops(OIF-null, drops(OIF-null, rate rate -limit etc) etc) Group: Group: 224.2.234.11, 224.2.234.11, Source Source count: count: 1, 1, Group Group pkt pkt count: count: 3244 3244 RP-tree: RP-tree: Forwarding: Forwarding: 3244/0/1198/0, 3244/0/1198/0, Other: Other: 3244/0/0 3244/0/0 Source: Source: 171.69.235.123/32, 171.69.235.123/32, Forwarding: Forwarding: 0/0/0/0, 0/0/0/0, Other: Other: 0/0/0 0/0/0 Group: Group: 224.2.247.22, 224.2.247.22, Source Source count: count: 3, 3, Group Group pkt pkt count: count: 369 369 RP-tree: RP-tree: Forwarding: Forwarding: 366/0/92/0, 366/0/92/0, Other: Other: 366/0/0 366/0/0 Source: 171.69.10.13/32, Forwarding: 0/0/0/0, Other: 0/0/0 Source: 171.69.10.13/32, Forwarding: 0/0/0/0, Other: 0/0/0 Source: Source: 171.69.200.191/32, 171.69.200.191/32, Forwarding: Forwarding: 0/0/0/0, 0/0/0/0, Other: Other: 19/0/19 19/0/19 Source: 3/113 Source: 171.69.248.71/32, 171.69.248.71/32, Forwarding: Forwarding: 3/0/112/0, 3/0/112/0, Other: Other: 239/12 239/12 3/113 .. .. ..

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

14 14

Useful for seeing statistics on each routing entry

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

14

show ip mcache

R6#show R6#show ip ip mcache mcache IP IP Multicast Multicast Fast-Switching Fast-Switching Cache Cache (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Ethernet1, Ethernet1, Last Last used: used: 00:02:33 00:02:33 Serial0 MAC Header: Serial0 MAC Header: 0F000800 0F000800 Serial1 MAC Header: 0F000800 Serial1 MAC Header: 0F000800

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

15 15

Displays IPmc fast switching cache - useful for debugging fast switching bugs

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

15

sh ip pim rp mapping
sjck-rp1>show sjck-rp1>show ip ip pim pim rp rp mapping mapping PIM -to-RP PIM Group Group -to-RP Mappings Mappings This system is an RP (Auto -RP) This system is an RP (Auto -RP) This This system system is is an an RP-mapping RP-mapping agent agent (Loopback1) (Loopback1) Group(s) Group(s) 224.0.0.0/4 224.0.0.0/4 RP sj-mbone-loopback0. cisco .com), RP 171.69.10.13 171.69.10.13 (( sj-mbone-loopback0. cisco .com), v2v1 v2v1 Info sj-mbone-loopback0. cisco .com), Info source: source: 171.69.10.13 171.69.10.13 (( sj-mbone-loopback0. cisco .com), via via Auto-RP Auto-RP Uptime: 4w4d, expires: 00:02:55 Uptime: 4w4d, expires: 00:02:55 Group(s) 239.192.111.0/24 Group(s) 239.192.111.0/24 RP cisco.com), RP 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1. cisco.com), v2v1 v2v1 Info cisco.com), Info source: source: 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1. cisco.com), via via Auto-RP Auto-RP Uptime: 1d18h, expires: 00:02:35 Uptime: 1d18h, expires: 00:02:35

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

16 16

This command lists the contents of the Group-to-RP Mapping Cache. In the example above, there are two group ranges covered by two different RPs, both of which have been learned via Auto-RP. (RPs can be learned either dynamically or by static configuration.) Note that there can be multiple RPs in the network each supporting a different multicast address range

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

16

show ip sdr
dallas-gw>show dallas-gw>show ip ip sdr sdr SDR SDR Cache Cache -- 450 450 entries entries *cisco *cisco 100k 100k Field Field *cisco *cisco 100K 100K Field Field Sales Sales Office Office *cisco 500k San *cisco 500k San Jose Jose && RTP RTP *cisco 500k SJ and RTP *cisco 500k SJ and RTP

. . . . . .

By default, sdr cache entries are not deleted - use the command ip sdr cache-timeout <minutes> to remove cache entries after a period of time.

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

17 17

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

17

show ip sdr detail


dallas-gw>show dallas-gw>show ip ip sdr sdr detail detail SDR SDR Cache Cache -- 450 450 entries entries Session Name: *cisco 100K Session Name: *cisco 100K Field Field Description: Description: 100K 100K Video Video Continuous Continuous Test Test Channel Channel Group: 0.0.0.0, ttl: 0, Contiguous Group: 0.0.0.0, ttl: 0, Contiguous allocation: allocation: 11 Uptime: Uptime: 3w0d, 3w0d, Last Last Heard: Heard: 00:09:44 00:09:44 Announcement Announcement source: source: 171.68.224.10 171.68.224.10 Created Created by: by: -- 27981 27981 25 25 IN IN IP4 IP4 171.68.224.8 171.68.224.8 Phone Phone number: number: TRC TRC <(408) <(408) 526-8888> 526-8888> Email: Email: URL: URL: http://171.68.223.153/CustAdv/InfoSys/TRC/guides/webcast.html http://171.68.223.153/CustAdv/InfoSys/TRC/guides/webcast.html Media: Media: video video 54002 54002 RTP/AVP RTP/AVP 31 31 32 32 96 96 Media Media group: group: 224.2.247.65, 224.2.247.65, ttl: ttl: 15 15 Attribute: quality:8 Attribute: quality:8 Attribute: framerate:20 Attribute: framerate:20 Attribute: :96 Attribute: rtpmap rtpmap :96 WBIH/90000 WBIH/90000 Media: 33 Media: audio audio 23704 23704 RTP/AVP RTP/AVP 33 00 14 14 55 96 96 97 97 98 98 99 99 100 100 101 101 102 102 10 10 Media Media group: group: 224.2.220.101, 224.2.220.101, ttl: ttl: 15 15 Attribute: :96 Attribute: rtpmap rtpmap :96 L8/22050/2 L8/22050/2 Attribute: :97 Attribute: rtpmap rtpmap :97 L8/22050 L8/22050 Attribute: :98 Attribute: rtpmap rtpmap :98 L8/11025/2 L8/11025/2 ... ...
Module4. ppt 8/10/2001 1:55 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

18 18

show ip sd [group | "session-name" | detail] Displays the contents of the session directory cache Example shown is an advertisement of a Cisco- internal IP/TV broadcast

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

18

Router Command Review

Show commands Debug commands Other useful commands

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

19 19

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

19

debug ip igmp

R4# R4# debug debug ip ip igmp igmp IGMP: IGMP: Send Send v2 v2 Query Query on on Ethernet1 Ethernet1 to to 224.0.0.1 224.0.0.1 IGMP: .1 IGMP: Received Received v2 v2 Report Report from from 172.16.7.2 172.16.7.2 (Ethernet1) (Ethernet1) for for 224.1.1 224.1.1 .1 IGMP: Received v2 Query from 172.16.6.1 IGMP: Received v2 Query from 172.16.6.1 (Ethernet0) (Ethernet0) IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth ernet0 IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth ernet0 IGMP: IGMP: Send Send v2 v2 Report Report for for 224.0.1.40 224.0.1.40 on on Ethernet0 Ethernet0 IGMP: .40 IGMP: Received Received v2 v2 Report Report from from 172.16.6.1 172.16.6.1 (Ethernet0) (Ethernet0) for for 224.0.1 224.0.1 .40 IGMP: Received v2 Report from 172.16.6.1 .40 IGMP: Received v2 Report from 172.16.6.1 (Ethernet0) (Ethernet0) for for 224.0.1 224.0.1 .40

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

20 20

This is a useful debug to make sure you are sending queries and to determine the query interval It is also useful for figuring out what IGMP version the clients are using - when the report back when queried

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

20

debug ip mpacket

R6# R6# debug debug ip ip mpacket mpacket 224.1.1.1 224.1.1.1 detail detail IP: IP: MAC MAC sa=00e0.b063.cf4b sa=00e0.b063.cf4b (Ethernet1), (Ethernet1), IP IP last-hop=172.16.12.2 last-hop=172.16.12.2 IP: IP tos=0x0, len =100, id=0x175, IP: IP tos=0x0, len =100, id=0x175, ttl=254, ttl=254, prot=1 prot=1 IP: s=172.16.12.2 (Ethernet1) d=224.1.1.1 len IP: s=172.16.12.2 (Ethernet1) d=224.1.1.1 len 114, 114, mroute mroute olist olist null null

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

21 21

Decode of a multicast packet USE CAUTION - when turning on packet level debugging especially when the router is servicing high multicast loads!

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

21

debug ip mroute

R6# R6# debug debug ip ip mrouting mrouting 224.1.1.1 224.1.1.1 MRT: MRT: Create Create (*, (*, 224.1.1.1), 224.1.1.1), RPF RPF Null, Null, PC PC 0x6032D254 0x6032D254 MRT: MRT: Create Create (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), RPF RPF Ethernet1/0.0.0.0, Ethernet1/0.0.0.0, PC PC x6032D378 x6032D378

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

22 22

Useful for watching multicast routing table maintenance

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

22

debug ip pim

R4# R4# debug debug ip ip pim pim 224.1.1.1 224.1.1.1 PIM: -Query PIM: Send Send Router Router -Query on on Ethernet0 Ethernet0 PIM: -Query PIM: Send Send Router Router -Query on on Ethernet1 Ethernet1 PIM: Received Router-Query PIM: Received Router-Query on on Ethernet0 Ethernet0 from from 172.16.6.1 172.16.6.1

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

23 23

Periodic Router-Query messages used to keep track of PIM neighbors. This creates and maintains neighbor adjacencies. There is no other PIM router on E1/1 but R3 is seen on E0/0

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

23

debug ip pim (cont)


R4# R4# PIM: PIM: Building Building Join/Prune Join/Prune message message for for 224.1.1.1 224.1.1.1 PIM: PIM: For For RP, RP, Join-list: Join-list: 172.16.8.1/32, 172.16.8.1/32, RP-bit, RP-bit, WC-bit WC-bit PIM: Send periodic Join/Prune to RP via PIM: Send periodic Join/Prune to RP via 172.16.6.1 172.16.6.1 (Ethernet0) (Ethernet0) PIM: Received RP -Reachable on Ethernet0 from 172.16.8.1 PIM: Received RP -Reachable on Ethernet0 from 172.16.8.1 for group 224.1.1.1 for group 224.1.1.1 PIM: PIM: Update Update RP RP expiration expiration timer timer (270 (270 sec) sec) for for 224.1.1.1 224.1.1.1

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

24 24

Here, the router is configured with the RP's address and hence sends out a periodic JOIN towards the RP. The RP in turn sends back an RP-Reachable message in return. The WC bits indicates (*,G) state setup.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

24

debug ip pim (cont)

R1# R1# PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: -list: -bit PIM: Join Join -list: (*, (*, 224.1.1.1) 224.1.1.1) RP RP 172.16.8.1, 172.16.8.1, RP-bit RP-bit set, set, SS -bit set set PIM: PIM: Add Add Serial0/172.16.3.2 Serial0/172.16.3.2 to to (*, (*, 224.1.1.1), 224.1.1.1), Forward Forward state state PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: PIM: Building Building Join/Prune Join/Prune message message for for 224.1.1.1 224.1.1.1 PIM: PIM: Send Send RP-reachability RP-reachability for for 224.1.1.1 224.1.1.1 on on Serial0 Serial0

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

25 25

On R1, which the RP for the Group 224.1.1.1 The RP receives periodic JOIN's for the (*,G) which is the pre-existing state in PIM Sparse mode. The RP updates its OIF for the (*,G) and sends back an RP-Reachability message.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

25

debug ip pim (cont)


R6# R6# PIM: PIM: Check Check RP RP 172.16.8.1 172.16.8.1 into into the the (*, (*, 224.1.1.1) 224.1.1.1) entry entry PIM: 11 PIM: Send Send Register Register to to 172.16.8.1 172.16.8.1 for for 172.16.12.2, 172.16.12.2, group group 224.1.1. 224.1.1. PIM: -Reachable PIM: Received Received RP RP -Reachable on on Serial1 Serial1 from from 172.16.8.1 172.16.8.1 PIM: -Reachable PIM: Received Received RP RP -Reachable on on Serial2 Serial2 from from 172.16.8.1 172.16.8.1

PIM: PIM: Received Received Join/Prune Join/Prune on on Ethernet0 Ethernet0 from from 172.16.9.1 172.16.9.1 PIM: -list: PIM: Join Join -list: (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), S-bit S-bit set set PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, rward PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Fo Fo rward state state PIM: Building Join/Prune message for 224.1.1.1 PIM: Building Join/Prune message for 224.1.1.1 PIM: No sources in join or prune list PIM: No sources in join or prune list PIM: PIM: Received Received Join/Prune Join/Prune on on Serial1 Serial1 from from 172.16.11.2 172.16.11.2 PIM: -list: PIM: Join Join -list: (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), S-bit S-bit set set PIM: ard PIM: Add Add Serial1/172.6.11.2 Serial1/172.6.11.2 to to (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Forw Forw ard state state PIM: PIM: Send Send Null Null Register Register to to 172.16.8.1 172.16.8.1 PIM: PIM: Received Received Register-Stop Register-Stop on on Ethernet0 Ethernet0 from from 172.16.8.1 172.16.8.1

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

26 26

Taken from R4 (router connected to the source) - this will show the initiation of the shared tree in PIM sparse mode Part 1 - When the Source initiates transmission to Group 224.1.1.1 R4 uses its (*,G) entry and sends the data to the RP encapsulated i n Register packets for the Source 172.16.12.2. Part 2 - It then creates a (S,G) entry of the form (172.16.12.2/24,224.1.1.1) JOIN's from its PIM Neighbors come in causing the interfaces on which the JOIN's are received to be added to the OIF -list in the Mroute table. Part 3 - R4 now starts sending periodic Null Register messages to the RP and receives Register-Stop messages. This is for maintenance of the tree.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

26

debug ip pim (cont)


R1# R1# PIM: PIM: Received Received Register Register on on Ethernet1 Ethernet1 from from 172.16.9.2 172.16.9.2 PIM: PIM: Forward Forward decapsulated decapsulated data data packet packet for for 224.1.1.1 224.1.1.1 on on Serial0 Serial0 --------PIM: Send Join on Ethernet1 to 172.16.8.2 for (172.16.12.2/32, 24.1.1.1) PIM: Send Join on Ethernet1 to 172.16.8.2 for (172.16.12.2/32, 22 24.1.1.1) PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: Join -list: (172.16.12.2/32, 224.1.1.1), S-bit set PIM: Join -list: (172.16.12.2/32, 224.1.1.1), S-bit set PIM: ard PIM: Add Add Serial0/172.16.3.2 Serial0/172.16.3.2 to to (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Forw Forw ard state state PIM: PIM: Send Send RP-reachability RP-reachability for for 224.1.1.1 224.1.1.1 on on Serial0 Serial0 --------PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: -list: -bit PIM: Join Join -list: (*, (*, 224.1.1.1) 224.1.1.1) RP RP 172.16.8.1, 172.16.8.1, RP-bit RP-bit set, set, SS -bit set set PIM: PIM: Add Add Serial0/172.16.3.2 Serial0/172.16.3.2 to to (*, (*, 224.1.1.1), 224.1.1.1), Forward Forward state state --------PIM: PIM: Building Building Join/Prune Join/Prune message message for for 224.1.1.1 224.1.1.1 PIM: PIM: For For 172.16.8.2, 172.16.8.2, Join-list: Join-list: 172.16.12.2/32 172.16.12.2/32 PIM: Send periodic Join/Prune to 172.16.8.2 PIM: Send periodic Join/Prune to 172.16.8.2 (Serial0) (Serial0) --------PIM: Received Register on Ethernet1 from 172.16.9.2 PIM: Received Register on Ethernet1 from 172.16.9.2 PIM: PIM: Send Send Register-Stop Register-Stop to to 172.16.9.2 172.16.9.2 for for 0.0.0.0, 0.0.0.0, group group 0.0.0.0 0.0.0.0 --------PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.8.2 172.16.8.2 PIM: -bit PIM: Prune-list: Prune-list: (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1) 224.1.1.1) RP RP -bit set set
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

27 27

On R1 (the RP) The RP receives the Register messages from Router R4, it decapsulates the data from the Source and forwards it down the tree towards the Receiver using the pre-existing (*,224.1.1.1) state. Sends a JOIN towards the Source for (S,G)-> (172.16.12.2,224.1.1.1) This builds the (S,G) mtree from the RP to the Source. (the stop the encapsulated data flow to a native IPmc flow) Meanwhile the (*,G) is periodically renewed by the routers on the Receiver side of the mtree. The RP continues to send out periodic JOIN's for (S,G) to maintain state. The RP continues to receive the Null Register messages sent out by R6. The RP then receives a PRUNE from R5 for (S,G) with the RP bit set. The RP bit indicates that the tree is switching from a Shared tree to the Shortest Path tree (SPT). The S bit also signifies the switch.
Copyright ? ?1998-2001, Cisco Systems, Inc.
Module4.ppt

27

Router Command Review

Show commands Debug commands Other useful commands

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

28 28

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

28

mtrace and mstat commands

Based on Unix mtrace command Split into two separate commands Both use the same mechanism
draft-ietf-idmr-traceroute-ipm-xx.txt

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

29 29

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

29

mtrace/mstatHow it works

Mtrace Packet Flow


Adds mtrace data Adds mtrace data Adds mtrace data Adds mtrace data Adds mtrace data

src
First-hop Router
Multicast Dist. Tree Mtrace Packet
mt rac e res po ns e

dest
st ue req

Last-hop Router

e rac mt

Note: Mtracepackets use special IGMP packets with IGMP Type codes of 0x1E and 0x1F.
Module4. ppt

Unix Workstation or Cisco Router


8/10/2001 1:55 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

30 30

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

30

mtrace/mstatHow it works
Uses a special IGMP packet type
IGMP type 0x1F = IGMP type 0x1E = Queries/Requests Response

Requestor sends Query/Request packet


Sent to last-hop router of destination Can be initiated by 3rd Party

Last-hop router rcvs Query packet


Converts packet to traceroute Request Unicasts to upstream router toward source
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

31 31

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

31

mtrace/mstatHow it works
Each hop adds data to packet

Module4. ppt

Query arrival time Incoming Interface Outgoing Interface Prev. Hop Router address Input packet count Output packet count Total packets for this Source/Group Routing Protocol TTL Threshold Forwarding/Error Code
8/10/2001 1:55 PM

1998 2001, Cisco Systems, Inc. All rights reserved.

32 32

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

32

mtrace/mstatHow it works

1st Hop router receives Request


Adds own response data Converts packet to Response type Sends response back to Requestor

Request receives Response packet


Packet contains hop-by-hop trace info

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

33 33

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

33

mtrace
Shows:
Multicast path from source to receiver.
Similar to unicast trace command Trace path between any two points in network TTL Thresholds & Delay shown at each node

Troubleshooting Usage:
Find where multicast traffic flow stops.
Focus on router where flow stops

Verify path multicast traffic is following.


Identify sub-optimal paths.
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

34 34

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

34

mtrace
dallas-gw>mtrace dallas-gw>mtrace bloom-iptv-svr bloom-iptv-svr bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Type escape sequence to abort. Type escape sequence to abort. Mtrace Mtrace from from 172.17.67.43 172.17.67.43 to to 171.68.37.121 171.68.37.121 via via group group 224.2.156.43 224.2.156.43 From From source source (?) (?) to to destination destination (bwilliam-ss5.cisco.com) (bwilliam-ss5.cisco.com) Querying Querying full full reverse reverse path... path... 0 0 bwilliam-ss5 bwilliam-ss5 (171.68.37.121) (171.68.37.121) -1 -1 dallas-gw dallas-gw (171.68.37.1) (171.68.37.1) PIM PIM thresh^ thresh^ 0 0 3 3 ms ms -2 -2 wan-gw4 wan-gw4 (171.68.86.193) (171.68.86.193) PIM PIM thresh^ thresh^ 0 0 32 32 ms ms -3 -3 bloomington-mn-gw bloomington-mn-gw (171.68.27.2) (171.68.27.2) PIM PIM thresh^ thresh^ 0 0 717 717 ms ms -4 -4 bloom-mnlab bloom-mnlab (171.68.39.28) (171.68.39.28) PIM PIM thresh^ thresh^ 0 0 730 730 ms ms -5 -5 bloom-iptv-svr bloom-iptv-svr (172.17.67.43) (172.17.67.43) dallas-gw> dallas-gw>

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

35 35

Shows all active groups with an aggregate bandwidth greater than the specified kbps (4kbps is the default) Listed in each entry is:
group address session name source address and domain name averaged pps and kbps rates for this flow

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

35

mstat
Shows:
Multicast path in pseudo graphic format.
Trace path between any two points in network Drops/Duplicates shown at each node TTLs & Delay shown at each node

Troubleshooting Usage:
Locate congestion point in the flow.
Focus on router with high drop/duplicate count Duplicates indicated as negative drops

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

36 36

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

36

mstat
dallas-gw>mstat dallas-gw>mstat 172.17.67.43 172.17.67.43 bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Source Response Packet Source Response Dest Dest Packet Statistics Statistics For For 172.17.67.43 171.68.86.194 All 172.17.67.43 171.68.86.194 All Multicast Multicast Traffic Traffic | __/ Lost/Sent | __/ rtt rtt 547 547 ms ms Lost/Sent = = Pct Pct Rate Rate v / hop --------------------v / hop 547 547 ms ms --------------------172.17.67.33 172.17.67.33 171.68.39.28 bloom 171.68.39.28 bloom-mnlab -mnlab | ^ ttl 0 | ^ ttl 0 v | hop -11/168 v | hop -409 -409 ms ms -11/168 = = --% --% 16 16 pps pps 171.68.39.1 171.68.39.1 171.68.27.2 bloomington-mn-gw 171.68.27.2 bloomington-mn-gw | ^ ttl 1 | ^ ttl 1 v | hop -9/170 17 v | hop 379 379 ms ms -9/170 = = --% --% 17 pps pps 171.68.27.1 171.68.27.1 171.68.86.193 wan 171.68.86.193 wan-gw4 -gw4 | ^ ttl 2 | ^ ttl 2 v | hop ms -3/195 19 v | hop 28 28 ms -3/195 = = --% --% 19 pps pps 171.68.86.194 171.68.86.194 171.68.37.1 dallas-gw 171.68.37.1 dallas-gw | \__ ttl 3 | \__ ttl 3 v \ ms 196 19 v \ hop hop 0 0 ms 196 19 pps pps 171.68.37.121 171.68.86.194 171.68.37.121 171.68.86.194 Receiver Query Receiver Query Source Source
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Only Only For For Traffic Traffic From From 172.17.67.43 172.17.67.43 To To 224.2.156.43 224.2.156.43 ---------------------------------------

0/67 0/67 = = 0% 0%

6 6 pps pps

-3/67 -3/67 = = --% --%

6 6 pps pps

0/70 0/70 = = 0% 0%

7 7 pps pps

70 70

7 7 pps pps

8/10/2001 1:55 PM

37 37

Shows all active groups with an aggregate bandwidth greater than the specified kbps (4kbps is the default) Listed in each entry is:
group address session name source address and domain name averaged pps and kbps rates for this flow

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

37

mstat
dallas-gw>mstat dallas-gw>mstat 172.17.67.43 172.17.67.43 bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Source Response Packet Source Response Dest Dest Packet Statistics Statistics For For 172.17.67.43 171.68.86.194 All 172.17.67.43 171.68.86.194 All Multicast Multicast Traffic Traffic | __/ Lost/Sent | __/ rtt rtt 399 399 ms ms Lost/Sent = = Pct Pct Rate Rate v / hop --------------------v / hop 399 399 ms ms --------------------172.17.67.33 172.17.67.33 171.68.39.28 bloom 171.68.39.28 bloom-mnlab -mnlab | ^ ttl 0 | ^ ttl 0 v | hop 77/694 v | hop 119 119 ms ms 77/694 = = 11% 11% 69 69 pps pps 171.68.39.1 171.68.39.1 171.68.27.2 bloomington-mn-gw 171.68.27.2 bloomington-mn-gw | ^ ttl 1 | ^ ttl 1 v | hop 395/609 v | hop -150 -150 ms ms 395/609 = = 65% 65% 60 60 pps pps 171.68.27.1 171.68.27.1 171.68.86.193 wan 171.68.86.193 wan-gw4 -gw4 | ^ ttl 2 | ^ ttl 2 v | hop ms -8/39 3 v | hop 30 30 ms -8/39 = = --% --% 3 pps pps 171.68.86.194 171.68.86.194 171.68.37.1 dallas-gw 171.68.37.1 dallas-gw | \__ ttl 3 | \__ ttl 3 v \ ms 39 3 v \ hop hop 0 0 ms 39 3 pps pps 171.68.37.121 171.68.86.194 171.68.37.121 171.68.86.194 Receiver Query Receiver Query Source Source
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Only Only For For Traffic Traffic From From 172.17.67.43 172.17.67.43 To To 224.2.156.43 224.2.156.43 ---------------------------------------

0/65 0/65 = = 0% 0%

6 6 pps pps

44/65 44/65 = = 68% 68%

6 6 pps pps

-1/21 -1/21 = = --% --%

2 2 pps pps

22 22

2 2 pps pps

8/10/2001 1:55 PM

38 38

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

38

mrinfo

berwyn-gw>mrinfo -gw berwyn-gw>mrinfo berwyn berwyn -gw 171.68.56.1 -gw.cisco.com) 171.68.56.1 (berwyn (berwyn -gw.cisco.com) [version [version cisco cisco 11.2] 11.2] [flags: [flags: PMSA]: PMSA]: 171.68.56.97 querier/leaf] 171.68.56.97 -> -> 0.0.0.0 0.0.0.0 [1/0/pim/ [1/0/pim/ querier/leaf] 171.68.56.1 171.68.56.1 -> -> 0.0.0.0 0.0.0.0 [1/0/pim/querier/leaf] [1/0/pim/querier/leaf] 171.68.28.142 171.68.28.142 -> -> 171.68.28.141 171.68.28.141 (wan-gw6.cisco.com) (wan-gw6.cisco.com) [1/0/pim] [1/0/pim]

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

39 39

Used to query a peering router about multicast information Example shown is from the Cisco internal network on a remote office router - when no arguments are given - the router queries itself

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

39

ping

ISP-251#ping ISP-251#ping 224.1.1.1 224.1.1.1 Type Type escape escape sequence sequence to to abort. abort. Sending -byte Sending 1, 1, 100 100 -byte ICMP ICMP Echos Echos to to 224.1.1.1, 224.1.1.1, timeout timeout is is 22 seconds: seconds: Reply Reply to to request request 00 from from 172.16.12.2, 172.16.12.2, 16 16 ms ms Reply Reply to to request request 00 from from 172.16.7.2, 172.16.7.2, 20 20 ms ms

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

40 40

Ping is the easiest way to generate multicast traffic in the lab and test the multicast tree Pings all members of the group - all members respond

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

40

Caching IP Multicast Packet Headers

You can view {source, group} traffic pairs IP ident and ttl Inter-packet delay Commands
ip multicast cache-headers show ip mpacket <source> <group> [detail]

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

41 41

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

41

Caching IP Multicast Packet Headers (Cont.)


dino-cisco-fr#show dino-cisco-fr#show ip ip mpacket mpacket cisco cisco-beta -beta IP IP Multicast Multicast Header Header Cache Cache - entry entry count: count: 29, 29, next next index: index: 30 30 Key: Key: id/ttl id/ttl timestamp timestamp (name) (name) source source group group D782/117 D782/117 7302/113 7302/113 6CB2/114 6CB2/114 D786/117 D786/117 E2E9/123 E2E9/123 1CA7/127 1CA7/127 1CAA/127 1CAA/127 1CAC/127 1CAC/127 1CAF/127 1CAF/127 1CB0/127 1CB0/127 1CB2/127 1CB2/127 2BBB/114 2BBB/114 3D1D/123 3D1D/123 2BC0/114 2BC0/114 7303/113 7303/113 7304/113 7304/113 2C7E/123 2C7E/123 206416.908 206416.908 206417.172 206417.172 206417.412 206417.412 206417.868 206417.868 206418.488 206418.488 206418.544 206418.544 206418.584 206418.584 206418.624 206418.624 206418.664 206418.664 206418.704 206418.704 206418.744 206418.744 206418.840 206418.840 206419.380 206419.380 206419.672 206419.672 206419.888 206419.888 206420.140 206420.140 206420.360 206420.360 (all-purpose-gunk.near.net) (all-purpose-gunk.near.net) 199.94.220.184 199.94.220.184 224.2.231.173 224.2.231.173 (speedy. (speedy.rrz rrz.uni .uni-koeln.de) -koeln.de) 134.95.19.23 134.95.19.23 224.2.231.173 224.2.231.173 ( wayback .uoregon.edu ) 128.223.156.117 224.2.231.173 ( wayback .uoregon.edu ) 128.223.156.117 224.2.231.173 (all-purpose-gunk.near.net) (all-purpose-gunk.near.net) 199.94.220.184 199.94.220.184 224.2.231.173 224.2.231.173 ( (dino-ss20.cisco.com) dino-ss20.cisco.com) 171.69.58.81 171.69.58.81 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (dino-ss2.cisco.com) dino-ss2.cisco.com) 171.69.129.220 171.69.129.220 224.2.231.173 224.2.231.173 ( (crevenia.parc.xerox crevenia.parc.xerox.com) .com) 13.2.116.11 13.2.116.11 224.2.231.173 224.2.231.173 ( (dalvarez-ss20.cisco.com) dalvarez-ss20.cisco.com) 171.69.60.189 171.69.60.189 224.2.231.173 224.2.231.173 ( (crevenia.parc.xerox crevenia.parc.xerox.com) .com) 13.2.116.11 13.2.116.11 224.2.231.173 224.2.231.173 (speedy. (speedy.rrz rrz.uni .uni-koeln.de) -koeln.de) 134.95.19.23 134.95.19.23 224.2.231.173 224.2.231.173 (speedy. (speedy.rrz rrz.uni .uni-koeln.de) -koeln.de) 134.95.19.23 134.95.19.23 224.2.231.173 224.2.231.173 ( (lwei-ss20.cisco.com) lwei-ss20.cisco.com) 171.69.58.88 171.69.58.88 224.2.231.173 224.2.231.173

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

42 42

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

42

Debugging Strategies

What does the network look like when everything is working? What is the expected behavior? What specifically is not working? Was it ever working correctly? What has been changed?

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

43 43

Debugging Strategies
These are standard questions to consider when debugging anything, including multicast

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

43

Debugging Strategies Troubleshooting Table


Source Signaling NA Network ? Receivers ?

Packet Flow

Is each piece working correctly?


Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

44 44

Debugging Strategies
Signaling is the process of setting up (and tearing down) the multicast session Packet flow is the actual sending, replication, and reception of the multicast packets based on the forwarding tables created by the signalling processes Each section of the table needs to be working for the application to work A similar table could be developed for unicast IP or other technologies, but the tools used to troubleshoot each case are different

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

44

Check source packet flow

Check interface counters on host Check upstream router for traffic flow
show ip mroute count show ip mroute active

debug ip mpacket on nearest upstream router *use with caution*


detail argument, or ACL for granularity

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

45 45

Checking source packet flow


How can we tell if the source is actually sourcing packets? First, check the interface counters on the source host to see if *it* thinks it is sending packets - if it doesnt, then it probably isnt. Check for misconfiguration or bugs in the host stack and application. Next, check the first upstream router or switch to see if it sees multicast packets from the source, using show commands Only if necessary, run debug ip mpacket on the route. This could have a serious performance impact on other traffic, so use with caution. The detail parameter for this command can be used to include packet headers in the debug output, and access lists can be used in conjunction with this command to check for traffic from specific sources.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

45

Check Network signaling

Most complex piece Depends of protocol, mode, etc. Check initial flow creation Check for pruning and timer expiration during session

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

46 46

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

46

Network signaling (continued)

show/debug ip mroute commands show/debug ip pim commands show/debug ip dvmrp commands show ip rpf
watch oilist for null entries

hop-by-hop process - use mtrace

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

47 47

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

47

PIM Sparse mode troubleshooting

show ip pim rp [<group>]


indicates RP for the group

show ip pim rp mapping


indicates RP for the group

debug ip pim auto-rp

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

48 48

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

48

DVMRP troubleshooting
show ip dvmrp route
can include address or interface arguments

debug ip dvmrp
Optional arguments are: detail - to capture headers ACL - to specify specific routes in | out - transmitted or recd only pruning - watch pruning and grafting only
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

49 49

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

49

Check Network packet flow

mstat command ping command show ip mroute count show ip mroute active debug ip mpacket
Be Careful with this one!

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

50 50

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

50

Check Receiver signaling

show ip igmp interface show ip igmp groups debug ip igmp / cgmp IGMPv1 vs. IGMPv2

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

51 51

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

51

Check Receiver packet flow

Check receiver interface stats Is the stack installed and configured properly? Is the application installed and configured properly? Watch for duplicates
performance implication

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 1:55 PM

52 52

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

52

Module4. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

53

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module4.ppt

53

PIM Sparse Mode


Module 5

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

Module Objectives

Identify and explain the basic mechanisms of PIM Sparse Mode. Configure and verify normal PIM SM operation.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

2 2

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

Module Agenda

Geekometer

PIM SM Overview PIM SM Protocol Mechanics PIM SM Review Configuring PIM SM

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

3 3

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM Sparse Mode Overview


Explicit join model
Receivers join to the Rendezvous Point (RP) Senders register with the RP Data flows down the shared tree and goes only to places that need the data from the sources Last hop routers can join source tree if the data rate warrants by sending joins to the source

RPF check depends on tree type


For shared trees, uses RP address For source trees, uses Source address
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

4 4

Explicit Join Model


Unlike PIM Dense mode, PIM Sparse mode uses the explicit join model whereby Receivers send PIM Join messages to a designated Rendezvous Point (RP). (The RP is the root of a shared distribution tree down which all multicast traffic flows.) In order to get multicast traffic to the RP for distribution down the shared tree, Senders send Register messages to the RP. Register messages cause the RP to send a Join towards the source so that multicast traffic can flow to the RP and hence down the shared tree. Last hop routers may be configured with an SPT-Threshold which, once exceeded, will cause the last hop router to join the Shortest Path Tree (SPT). This will result in the multicast traffic from the source to flow down the SPT from the source to the last hop router.

RPF Check depends on tree type


If traffic is flowing down the shared tree, the RPF check mechanism will use the IP address of the RP to perform the RPF check. If traffic is flowing down the SPT, the RPF check mechanism will use the IP address of the Source to perform the RPF check.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM Sparse Mode Overview

Only one RP is chosen for a particular group RP statically configured or dynamically learned (Auto-RP or PIM v2 BSR) Data forwarded based on the source state (S, G) if it exists, otherwise use the shared state (*, G) RFC 2362 - PIM Sparse Mode Protocol Spec

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

5 5

Only one RP for a group may be active at a time


While it is usually the case that a single RP serves all groups, it is possible to configure different RPs for a range(s) group(s). This is accomplished via access-lists. This permits the RPs to be placed in different locations and can improve the traffic flow for the group if it is placed close to the Source(s).

RP Configuration
RPs may be configured statically on each router (although they must all agree or your network will be broken!) in your network. However, a better solution is to use the Auto-RP or PIMv2 mechanisms to configure RPs.

Data Forwarding
Multicast traffic forwarding In a PIM Sparse mode network is first attempted using any matching (S,G) entries in the Multicast Routing table. If no matching (S,G) state exists, then the traffic is forwarded using the matching (*,G) entry in the Multicast Routing table.

PIM Sparse Mode Spec


PIM Sparse mode is now defined in RFC 2362.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM-SM Shared Tree Joins

RP

( * , G) Joins Shared Tree Receiver

( * , G) State created only along the Shared Tree.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

6 6

PIM-SM Shared Tree Joins


In this example, there is an active receiver (attached to leaf router at the bottom of the drawing) has joined multicast group G. The leaf router knows the IP address of the Rendezvous Point (RP ) for group G and when it sends a (*,G) Join for this group towards the RP. This (*, G) Join travels hop-by-hop to the RP building a branch of the Shared Tree that extends from the RP to the last-hop router directly connected to the receiver. At this point, group G traffic can flow down the Shared Tree to the receiver.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM-SM Sender Registration

Source

RP

(S, G) Register (S, G) Joins Shared Tree Source Tree

(unicast)

(S, G) State created only along the Source Tree.

Receiver

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

7 7

PIM-SM Sender Registration


As soon as an active source for group G sends a packet the leaf router that is attached to this source is responsible for Registering this source with the RP and requesting the RP to build a tree back to that router. The source router encapsulates the multicast data from the source in a special PIM SM message called the Register message and unicasts that data to the RP. When the RP receives the Register message it does two things It de-encapsulates the multicast data packet inside of the Register message and forwards it down the Shared Tree. The RP also sends an (S,G) Join back towards the source network S to create a branch of an (S, G) Shortest-Path Tree. This results in (S, G) state being created in all the router along the SPT, including the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM-SM Sender Registration

Source

RP

(S, G) Register (S, G) Joins Shared Tree Source Tree (S, G) Register-Stop

(unicast)

RP sends Register-Stop back to first-hop router.

(unicast)

Receiver

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

8 8

PIM-SM Sender Registration (cont.)


As soon as the SPT is built from the Source router to the RP, multicast traffic begins to flow natively from source S to the RP. Once the RP begins receiving data natively (i.e. down the SPT) from source S it sends a Register Stop to the sources first hop router to inform it that it can stop sending the unicast Register messages.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM-SM Sender Registration

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

Source traffic flows natively along SPT to RP. From RP, traffic flows down the Shared Tree to Receivers.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

9 9

PIM-SM Sender Registration (cont.)


At this point, multicast traffic from the source is flowing down the SPT to the RP and from there, down the Shared Tree to the receiver.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

PIM-SM SPT Switchover

Source

RP

Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes Additional (S, G) State is created along new part of the Source Tree. Receiver Additional (S, G) State is created along along the Shared Tree to prune off (S, G) traffic.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

10 10

PIM-SM Shortest-Path Tree Switchover


PIM-SM has the capability for last-hop routers (i.e. routers with directly connected members) to switch to the Shortest-Path Tree and bypass the RP if the traffic rate is above a set threshold called the SPT-Threshold. The default value of the SPT-Threshold in Cisco routers is zero. This means that the default behaviour for PIM-SM leaf routers attached to active receivers is to immediately join the SPT to the source as soon as the first packet arrives via the (*,G) shared tree. In the above example, the last-hop router (at the bottom of the drawing) sends an (S, G) Join message toward the source to join the SPT and bypass the RP. This (S, G) Join messages travels hop-by-hop to the first-hop router (i.e. the router connected directly to the source) thereby creating another branch of the SPT. This also creates (S, G) state in all the routers along this branch of the SPT. Finally, special (S, G)RP-bit Prune messages are sent up the Shared Tree to prune off this (S,G) traffic from the Shared Tree. If this were not done, (S, G) traffic would continue flowing down the Shared Tree resulting in duplicate (S, G) packets arriving at the receiver.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

10

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

(S, G) Traffic flow is now pruned off of the Shared Tree and is flowing to the Receiver via the SPT.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

11 11

PIM-SM Shortest-Path Tree Switchover


At this point, (S, G) traffic is now flowing directly from the first -hop router to the last-hop router and from there to the receiver. Note: The RP will normally send (S, G) Prunes back toward the source to shutoff the flow of now unnecessary (S, G) traffic to the RP IFF it has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree. (This step has been omitted from the example above.) As a result of this SPT-Switchover mechanism, PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

11

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree (S, G) Prune Receiver

(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.

Module5.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

12 12

PIM-SM Shortest-Path Tree Switchover


At this point, the RP no longer needs the flow of (S, G) traffic since all branches of the Shared Tree (in this case there is only one) have pruned off the flow of (S, G) traffic. As a result, the RP will send (S, G) Prunes back toward the source to shutoff the flow of the now unnecessary (S, G) traffic to the RP Note: This will occur IFF the RP has received an (S, G)RP-bit Prune on all interfaces on the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

12

PIM-SM SPT Switchover

Source

RP

Traffic Flow Shared Tree Source Tree Receiver

(S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree.

Module5.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

13 13

PIM-SM Shortest-Path Tree Switchover


As a result of the SPT-Switchover, (S, G) traffic is now only flowing from the first-hop router to the last-hop router and from there to the receiver. Notice that traffic is no longer flowing to the RP. As a result of this SPT-Switchover mechanism, it is clear that PIM SM also supports the construction and use of SPT (S,G) trees but in a much more economical fashion than PIM DM in terms of forwarding state.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

13

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

14 14

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

14

PIM Neighbor Discovery


171.68.37.2 PIM Router 2 Highest IP Address elected as DR (Designated Router) PIM Hello

PIM Hello PIM Router 1 171.68.37.1

PIMv2 Hellos are periodically multicast to the All-PIM-Routers (224.0.0.13) group address. (Default = 30 seconds)
Note: PIMv1 multicasts PIM Query messages to the All-Routers (224.0.0.2) group address.

If the DR times-out, a new DR is elected. The DR is responsible for sending all Joins and Register messages for any receivers or senders on the network.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

15 15

PIM Neighbor Discovery


PIM Hellos are sent periodically to discover the existence of other PIM routers on the network and to elect the Designated Router. For Multi-Access networks (e.g. Ethernet), the PIM Hello messages are multicast to the All-PIM -Routers (224.0.0.13) multicast group address.

Designated Router (DR)


For multi-access networks, a Designated Router (DR) is elected. In PIM Sparse mode networks, the DR is responsible for sending Joins to the RP for members on the multi-access network and for sending Registers to the RP for sources on the multi-access network. For Dense mode, the DR has no meaning. The exception to this is when IGMPv1 is in use. In this case, the DR also functions as the IGMP Querier for the Multi-Access network.

Designated Router (DR) Election


To elect the DR, each PIM node on a multi-access network examines the received PIM Hello messages from its neighbors and compares the IP Address of its interface with the IP Address of its PIM Neighbors. The PIM Neighbor with the highest IP Address is elected the DR. If no PIM Hellos have been received from the elected DR after some period (configurable), the DR Election mechanism is run again to elect a new DR.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

15

PIM Neighbor Discovery


wan-gw8> show wan-gw8> show ip ip pim pim neighbor neighbor PIM PIM Neighbor Neighbor Table Table Neighbor Neighbor Address Address Interface Interface 171.68.0.70 FastEthernet0 171.68.0.70 FastEthernet0 171.68.0.91 FastEthernet0 171.68.0.91 FastEthernet0 171.68.0.82 FastEthernet0 171.68.0.82 FastEthernet0 171.68.0.86 FastEthernet0 171.68.0.86 FastEthernet0 171.68.0.80 FastEthernet0 171.68.0.80 FastEthernet0 171.68.28.70 Serial2.31 171.68.28.70 Serial2.31 171.68.28.50 Serial2.33 171.68.28.50 Serial2.33 171.68.27.74 Serial2.36 171.68.27.74 Serial2.36 171.68.28.170 Serial0.70 171.68.28.170 Serial0.70 171.68.27.2 Serial1.51 171.68.27.2 Serial1.51 171.68.28.110 Serial3.56 171.68.28.110 Serial3.56 171.68.28.58 Serial3.102 171.68.28.58 Serial3.102

Uptime Uptime 2w1d 2w1d 2w6d 2w6d 7w0d 7w0d 7w0d 7w0d 7w0d 7w0d 22:47:11 22:47:11 22:47:22 22:47:22 22:47:07 22:47:07 1d04h 1d04h 1w4d 1w4d 1d04h 1d04h 12:53:25 12:53:25

Expires Expires 00:01:24 00:01:24 00:01:01 00:01:01 00:01:14 00:01:14 00:01:13 00:01:13 00:01:02 00:01:02 00:01:16 00:01:16 00:01:08 00:01:08 00:01:21 00:01:21 00:01:06 00:01:06 00:01:25 00:01:25 00:01:20 00:01:20 00:01:03 00:01:03

Mode Mode Sparse Sparse Sparse Sparse (DR) (DR) Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

16 16

show ip pim neighbor command output


Neighbor Address - the IP address of the PIM Neighbor Interface - the interface where the PIM Hello of this neighbor was received. Uptime - the period of time that this PIM Neighbor has been active. Expires - the period of time after which this PIM Neighbor will no longer be considered as active. (Reset by the receipt of a another PIM Query.) Mode - PIM mode (Sparse, Dense, Sparse/Dense) that the PIM Neighbor is using. (DR) - Indicates that this PIM Neighbor is the Designated Router for the network.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

16

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

17 17

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

17

PIM State

Describes the state of the multicast distribution trees as understood by the router at this point in the network. Represented by entries in the multicast routing (mroute) table
Used to make multicast traffic forwarding decisions Composed of (*, G) and (S, G) entries Each entry contains RPF information
Incoming (i.e. RPF) interface RPF Neighbor (upstream)

Each entry contains an Outgoing Interface List (OIL)


OIL may be NULL

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

18 18

PIM State
In general, Multicast State basically describes the multicast distribution tree as it is understood by the router at this point in the network. However to be completely correct, Multicast State describes the multicast traffic forwarding state that is used by the router to forward multicast traffic.

Multicast Routing (mroute) Table


Multicast state is stored in the multicast routing (mroute) table and which can be displayed using the show ip mroute command. Entries in the mroute table are composed of (*, G) and (S, G) entries each of which contain: RPF Information consisting of an Incoming (or RPF) interface and the IP address of the RPF (i.e. upstream) neighbor router in the direction of the source. (In the case of PIM-SM, this information in a (*, G) entry points toward the RP. PIM-SM will be discussed in a later module.) Outgoing Interface List (OIL) which contains a list of interfaces that the multicast traffic is to be forwarded. (Multicast traffic must arrive on the Incoming interface before it will be forwarded out this interfaces. If multicast traffic does not arrive on the Incoming interface, it is simply discarded.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

18

PIM-SM State Example


sj-mbone> 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 (*, 224.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, 224.1.1.1), Incoming interface: Serial0, Outgoing interface list: Ethernet1, Forward/Sparse, Ethernet0, forward/Sparse, 00:01:43/00:02:59, flags: CJT RPF nbr 192.10.2.1 00:01:43/00:02:11 00:01:43/00:02:11

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

19 19

PIM-SM State Example


(*, G) Entry - The (*, 224.1.1.1) entry shown in sample output of the show ip mroute command is the (*, G) entry. If there is no matching entry for a particular (S, G) entry, this entry is used to forward traffic down the Shared Tree. The Expires countdown timer in the first line of the (*, G) entry which shows when the entry will expire and be deleted. This entry will remain at roughly 3 minutes as long as there is an interface in the Outgoing Interface list. The Incoming interface information is used to RPF check arriving (*, G) multicast traffic and is computed in the direction of the RP (in this case, 10.1.5.1.). The Outgoing Interface list which reflects the interfaces where (*,G) Joins have been received or where directly connected members of group G reside. Traffic flowing down the Shared Tree are forwarded out these interfaces. The Expires countdown timers on these interfaces are reset to 3 minutes by the receipt of periodic (*, G) Joins. If the count ever reaches zero, the entry in the OIL is deleted. (S, G) Entry - The (128.9.160.43/32, 224.1.1.1) entry is an example of an (S, G) entry in the mroute table. This entry is used to forward any multicast traffic sent by source 128.9.160.43 to group 224.1.1.1. Notice the following: The Expires countdown timer in the first line of the (S, G) entry which shows when the entry will expire and be deleted. This entry is reset to 3 minutes whenever an (S, G) multicast packet is forwarded. The Incoming interface information is used to RPF check arriving (S, G) multicast traffic. If a packet does not arrive via this interface, the packet is discarded. The Outgoing Interface list which reflects the interfaces where (S,G) packets are to be forwarded.
Copyright ? ?1999-2001, Cisco Systems, Inc.
Module5.ppt

19

PIM-SM (*,G) State Rules


(*,G) creation
Receipt of a (*,G) Join or IGMP Report Automatically if (S,G) must be created

(*,G) reflects default group forwarding


IIF = RPF interface toward RP OIL = interfaces
that received a (*,G) Join or with directly connected members or manually configured

(*,G) deletion
When OIL = NULL and no child (S,G) state exists
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

20 20

PIM-SM (*,G) State Rules


A (*, G) entry is created when a (*, G) Join or an IGMP Report is received The later condition can be simulated by manually configuring the interface to join the group. (*, G) entries are also automatically created whenever an (S, G) entry for the group must be created. The (*, G) entry is created first and then the (S, G) entry. The reason for this will become clear shortly. The IIF reflects the RPF interface/neighbor in the direction of the RP. The OIL of a PIM-SM (*, G) entry reflects interfaces that: Have received a (*, G) Join or Where a directly connected member has joined the group The interface was manually configured to join the group. (Note: This may be accomplished using the ip igmp static-group <group> command.) (*, G) entries are deleted when its Expires timer counts down to zero. This will only occur when: The OIL is Null and No child (S, G) entry exists

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

20

PIM-SM (S,G) State Rules


(S,G) creation
By receipt of (S,G) Join or Prune or By Register process Parent (*,G) created (if doesnt exist)

(S,G) reflects forwarding of S to G


IIF = RPF Interface normally toward source
RPF toward RP if RP-bit set

OIL = Initially, copy of (*,G) OIL minus IIF

(S,G) deletion
By normal (S,G) entry timeout
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

21 21

PIM-SM (S, G) Rules


In PIM -SM, (S, G) state is created as a result of: The receipt of an (S, G) Join or Prune or The PIM -SM Register process which is triggered by a first-hop router receiving a packet from a directly connected source. When an (S, G) entry must be created, the following steps occur: If a corresponding (*, G) entry does not exist, it is created first. The RPF Information is computed for the source S. This information is stored in the (S, G) entry as the Incoming interface and the RPF neighbor (i.e. the PIM neighbor in the direction of the source). The exception to this rule is if the RP-bit is set in the (S, G) entry, the RPF interface is pointed up the Shared Tree. This mechanism allows duplicate (S, G) traffic to be blocked from flowing down the Shared Tree after a downstream router has switched to the Shortest Path Tree. (More on this later.) The OIL of the (S, G) entry is populated with a copy of the OIL from the parent (*, G) entry less the Incoming interface. (The Incoming interface must not appear in the OIL otherwise a multicast route loop could occur.) In PIM -SM, (S, G) entries are deleted when their Expires timer counts down to zero. The Expires timer is reset whenever an (S, G) packet is received and forwarded.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

21

PIM-SM OIL Rules


Interfaces in OIL added
By receipt of Join message
Interfaces added to (*,G) are added to all (S,G)s

Interfaces in OIL removed


By receipt of Prune message
Interfaces removed from (*,G) are removed from all (S,G)s

Interface Expire timer counts down to zero


Timer reset (to 3 min.) by receipt of periodic Join or By IGMP membership report
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

22 22

PIM-SM Outgoing Interface List Rules


Adding an interface Interfaces are added to an (S, G) OIL when a (S, G) Join message is received on an interface. Interfaces are added to the (*, G) OIL when a (*, G) Join message is received on an interface. Anytime an interface is added to the (*, G) OIL, the interface is added to the OIL of all associated (S, G) OILs. (Note: A check is always made to prevent the IIF from appearing in the OIL.) Removing an interface Interfaces are removed from the OIL of a (*, G) or (S, G) entry if the interfaces Expires timer counts down to zero. Note: The interface Expires timer is reset to 3 minutes by the receipt of periodic Join messages sent by downstream routers once per minute or by an IGMP Report sent by a directly connected member on the interface. Interfaces are removed from the OIL if an Prune message is received (and it is not overridden by another router if the interface is a multi-access network). Interfaces removed from a (*, G) OIL, are removed from the OIL of all associated (S, G) OILs.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

22

PIM-SM OIL Rules


Triggering Join/Prune Messages
(*,G) Joins are triggered when:
The (*,G) OIL transitions from Null to non-Null

(*,G) Prunes are triggered when:


The (*,G) OIL transitions from non-Null to Null

(S,G) Joins are triggered when:


The (S,G) OIL transitions from Null to non-Null

(S,G) Prunes are triggered when:


The (S,G) OIL is Null AND A packet is received on the incoming interface

(S,G)RP-bit Prunes are triggered when:


The (S,G) RPF info != the (*,G) RPF info
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

23 23

PIM-SM Outgoing Interface List Rules


Triggering Join/Prune Messages (*,G) Joins are triggered whenever the (*,G) OIL is empty (Null) and an interface is added making the OIL non-Null. (*,G) Prunes are triggered whenever the last interface is removed from the (*,G) OIL. (S,G) Joins are triggered whenever the (S,G) OIL is empty (Null) and an interface is added making the OIL non-Null. (S,G) Prunes are triggered whenever the (S,G) OIL is empty AND a packet is received on the incoming interface. Note: This is an optimization that attempts to minimize the sending of (S,G) Prunes. Instead of sending the (S,G) Prune immediately when the last interface is removed, the state is just allowed to time out. However, if (S,G) traffic is still flowing, then the arrival of the next (S,G) packet will cause the prune to be sent. (S,G)RP -bit Prunes are sent whenever the (S,G) RPF information (incoming interface and RPF-neighbor) is not the same as the (*,G) RPF information. This indicates that the SPT and the Shared-Tree diverge at this point and that (S,G) traffic should be pruned from the Shared-Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

23

PIM-SM State Flags

S C L P T

= = = = =

Sparse Mode Directly Connected Host Local (Router is member) Pruned (All intfcs in OIL = Prune) Forwarding via SPT

Indicates at least one packet was forwarded

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

24 24

PIM-SM State Flags


S Flag ((*, G) entries only) Indicates the group is operating in Sparse mode. (Appears only on (*, G) entries.) C Flag Indicates that there is a member of the group directly connected to the router. L Flag Indicates the router itself is a member of this group and is receiving the traffic. (This would be the case for the Auto-RP Discovery group 224.0.1.40 which all Cisco routers join automatically.) P Flag Set whenever all interfaces in the outgoing interface list of an entry are Pruned (or the list is Null). This general means that the router will send Prune messages to the RPF neighbor to try to shutoff this traffic.) T Flag ((S, G) entries only) Indicates that at least one packet was received via the SPT

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

24

PIM-SM State Flags (cont.)


J = Join SPT
Indicates SPT-Threshold is being exceeded Next (S,G) received will trigger join of SPT

In (*, G) entry

In (S, G) entry
Indicates SPT joined due to SPT-Threshold If rate < SPT-Threshold, switch back to Shared Tree

F = Register
In (S,G) entry
S is a directly connected source Triggers the Register Process

In (*, G) entry
Set when F set in at least one child (S,G)
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

25 25

PIM-SM State Flags


J Flag (Join SPT) When this flag is set in a (*, G) entry, it indicates that the rate of traffic flowing down the Shared Tree is above the SPT-Threshold and will cause a switch to the SPT for the next packet received down the shared tree. (More on this later.) When this flag is set in an (S, G) entry, it indicates that the (S, G) entry (and hence the SPT) was created as a result of the SPT-Threshold being exceeded. If the rate of this (S, G) traffic drops back below the SPT, the router will attempt to switch this traffic flow back to the Shared Tree. F Flag (Register) This flag is set on an (S, G) entry when source S is directly connected to the router. This indicates that this router is a first-hop router and triggers it to send Register messages to the RP to inform the RP of this active source. This flag can also be set for arriving (S, G) entries created at a border router such as a router that borders on a DVMRP or other dense mode cloud. This causes the router to perform a proxy-register operation and send (S, G) Register messages to the RP on behalf of the downstream DVMRP routers. This proxy-register operation follows the same rules as for directly connected sources. The F flag is also set on a (*, G) entry if any associated (S, G) entries have the F flag set.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

25

PIM-SM State Flags (cont.)


R = RP bit
(S, G) entries only Set by (S,G)RP-bit Prune Indicates info is applicable to Shared Tree Used to prune (S,G) traffic from Shared Tree
Initiated by Last-hop router after switch to SPT

Modifies (S,G) forwarding behavior


IIF = RPF toward RP (I.e. up the Shared Tree) OIL = Pruned accordingly
26 26

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

PIM-SM Flags
R Flag (RP-Bit) This flag is set on (S, G) entries only and indicates that the (S, G) forwarding information in the entry is applicable to (S, G) traffic flowing down the Shared Tree. The R flag is set on an (S, G) entry by the receipt of an (S, G)RP-bit Prune message. These messages are sent by downstream routers on the Shared Tree that are requesting that this specific (S, G) traffic flow be pruned off of the Shared Tree. This is done to eliminate duplicate (S, G) traffic after a downstream router has switched to the (S, G) Shortest-Path Tree. Whenever the R flag is set on an (S, G) entry, the RPF information must be changed to point toward the RP instead of pointing at source S. This is done because the (S, G) entry is now applicable to (S, G) traffic arriving down the Shared Tree. As a result, the RPF information must point up the Shared Tree in order for arriving (S, G) packets to RPF correctly. (This should be made clear later.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

26

PIM-SM State Flags (cont.)

X = Proxy Join Timer flag


(S, G) entries only Indicates Proxy Join Timer is running Used to handle turn-around router case
More on this in another Module

When Proxy Join Timer is running


(S, G) Joins are sent toward the source The sending of (S, G) Prunes are suppressed
Even if the OIL list is NULL

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

27 27

PIM-SM Flags
X Flag (Proxy Join Timer Running) This flag is set on (S, G) entries only and is used to indicate that the Proxy Join Timer is running. When this timer is running, the router will continue to send (S, G) Joins in the direction of the source even if the OIL is NULL. This is used to handle the special turn-around router situation which occurs when the SPT to the RP and the Shared Tree merge. (More on this special scenario will be presented in another module.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

27

PIM-SM State Flags (cont.)


M = MSDP Created bit
(S, G) entries only Set when (S, G) learned via an MSDP SA msg

A = MSDP Advertise bit


(S, G) entries only (S, G) may be advertised in an MSDP SA msg
Presence of certain filters can affect this.

Indicates source is in local SM domain


Received a PIM (S,G) Register or Source is directly connected or (S,G) traffic was received on a DM interface
via the RPF interface
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

28 28

PIM-SM Flags
M Flag (MSDP Created) This flag only appears on (S, G) entries and only on the router that is the active RP for group G. The flag indicates that the RP has learned of this particular source via an MSDP Source Active message. (MSDP is addressed in more detail in another module.) A Flag (Advertise Flag) This flag only appears on (S, G) entries and only on the router that is the active RP for group G. The A flag indicates that this source is in the local PIM-SM domain and that it is a candidate for being announced to RPs in other networks via MSDP Source Active messages. A source is considered to be in the local domain if an (S, G) Register message was received for this source or the source is directly connected to the RP or the (S, G) traffic was received on a Dense mode interface that has been designated as a dense mode boundary interface.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

28

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

29 29

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

29

PIM SM Joining

Leaf routers send a (*,G) Join toward RP


Joins sent hop-by-hop along path toward RP

Each router along path creates (*,G) state


IF no (*,G) state,
Create it and send a Join toward RP

ELSE
Join process complete. Reached the Shared Tree.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

30 30

Leaf (last-hop) routers join the Shared Tree (RPT)


When a last-hop router wishes to begin receiving multicast traffic for group G, it sends a PIM (*,G) Join message to its up-stream PIM Neighbor in the direction of the RP. While the Join is multicast to the All-Routers (224.0.0.2) multicast address, the up-stream PIM Neighbors IP address is indicated in the body of the PIM Join Message. This permits all PIM routers on a Multi-Access network to be aware of the Join but only the indicated up-stream PIM Neighbor will perform the Join.

Routers up the Shared Tree (RPT) create (*,G) state


When a PIM router receives a (*,G) Join for group G from one of its downstream PIM Neighbors, it will check to see if any (*, G) state exists for group G in its Multicast Routing table. If (*, G) state for group G already exists, then the interface from which the Join was received is placed on the (*,G) oilist. If no (*, G) state for group G exists, a (*, G) entry is created, the interface from which the Join was received is placed in the (*, G) oilist and a (*, G) Join is sent towards the RP. The end result of the above mechanism is to create (*, G) state all the way from the last-hop router to the RP so that group G multicast traffic will flow down the Shared Tree (RPT) to the last-hop router.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

30

PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2

S1

rtr-a
E0
10.1.2.1

E0

1 IGMP Join
Rcvr A

E1

rtr-b

Rcvr A wishes to receive group G traffic. Sends IGMP Join for G.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

31 31

PIM SM Joining Example


1) Receiver A wishes to receive group G multicast traffic and therefore sends an IGMP Host Membership message (sometimes loosely referred to as an IGMP Join) which is received by rtr-b. rtr-b has no existing (*, G) state for group G and therefore creates an entry. (See next slide.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

31

PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2

S1

rtr-a
E0
10.1.2.1

E0

E1
Rcvr A

rtr-b

(*, (*, 224.1.1.1), 224.1.1.1), 00:00:05/00:02:54, 00:00:05/00:02:54, RP RP 10.1.5.1, 10.1.5.1, flags: flags: SC SC Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1 10.1.2.1 Outgoing Outgoing interface interface list: list: Ethernet1, Forward/Sparse, 00:00:05/00:02:54 Ethernet1, Forward/Sparse, Forward/Sparse, 00:00:05/00:02:54 00:00:05/00:02:54

rtr-b creates (*, 224.1.1.1) state

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

32 32

State in rtr-b after Joining (*, 224.1.1.1)


(*, 224.1.1.1) indicates the (*, G) entry. 00:00:05/00:02:54 indicates that the entry has existed for 5 seconds and will expire in 2 minutes and 54 seconds. RP 10.1.5.1 is the IP Address of the Rendezvous Point for Group 224.1.1.1 flags: SC indicates that this is a Sparse mode group (S) and that there is a member of this group directly connected (C) to the router. Incoming interface: Ethernet0, RPF nbr 10.1.2.1 indicates the Incoming interface (up the Shared Tree toward RP) and the RPF neighbors IP address (in the direction of the RP) is 10.1.2.1 Outgoing interface list: lists the interfaces that are in the outgoing interface list for this entry. Ethernet1, Forward/Sparse, 00:00:05/00:02:54 indicates Ethernet 1 is in the oilist; its in the Forward state; Sparse mode and that it has been in the list for 5 seconds and will expire in 2 minutes and 54 seconds if no further (*, G) Join or IGMP Report is received on this interface.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

32

PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2

S1

rtr-a
E0
10.1.2.1

E0

2 PIM Join

E1
Rcvr A

rtr-b

1 2

Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends (*,G) Join towards RP.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

33 33

PIM SM Joining Example


2) Because the OIL of the (*, G) transitioned from Null to non-Null (when rtr-b added Ethernet 1 to the OIL of the newly created entry), a PIM (*, G) Join is sent to rtr-bs up-stream PIM neighbor (rtr-a) in the direction of the RP. When rtr-a receives the (*, G) Join it creates (*, G) state. (See next slide.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

33

PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2

S1

rtr-a
E0
10.1.2.1

E0

E1
Rcvr A

rtr-b

(*, (*, 224.1.1.1), 224.1.1.1), 00:00:05/00:02:54, 00:00:05/00:02:54, RP RP 10.1.5.1, 10.1.5.1, flags: flags: S S Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 10.1.4.1 10.1.4.1 Outgoing Outgoing interface interface list: list: Ethernet0, Ethernet0, 00:00:05/00:02:54 Ethernet0, Forward/Sparse, Forward/Sparse, 00:00:05/00:02:54 00:00:05/00:02:54

rtr-a creates (*, 224.1.1.1) state.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

34 34

State in rtr-a after Joining (*, 224.1.1.1)


(*, 224.1.1.1) indicates the (*, G) entry. 00:00:05/00:02:54 indicates that the entry has existed for 5 seconds and will expire in 2 minutes and 54 seconds. RP 10.1.5.1 is the IP Address of the Rendezvous Point for Group 224.1.1.1 flags: S indicates that this is a Sparse mode group (S). Incoming interface: Serial0, RPF nbr 10.1.4.1 indicates the Incoming interface (up the Shared Tree toward RP) and the RPF neighbors IP address (in the direction of the RP) is 10.1.4.1 Outgoing interface list: lists the interfaces that are in the outgoing interface list for this entry. Ethernet0, Forward/Sparse, 00:00:05/00:02:54 indicates Ethernet 0 is in the oilist; its in the Forward state; Sparse mode and that it has been in the list for 5 seconds and will expire in 2 minutes and 54 seconds if no further (*, G) Join or IGMP Report is received on this interface.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

34

PIM SM Joining
To RP (10.1.5.1) 4 Shared Tree S0
10.1.4.2

S1

3 PIM Join
Shared Tree

rtr-a
E0
10.1.2.1

10.1.2.2

E0

E1
Rcvr A

rtr-b

1 2 3 4

Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends (*,G) Join towards RP. rtr-a sends (*,G) Join towards RP. Shared tree is built all the way back to the RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

35 35

PIM SM Joining Example


3) Because the OIL of the (*, G) transitioned from Null to non-Null (when rtr-a added Ethernet 0 to the OIL of the newly created entry), a PIM (*, G) Join is sent to rtr-as up-stream PIM neighbor in the direction of the RP. When the upstream router receives the (*, G) Join it too creates (*, G) state and creates a branch of the Shared Tree. 4) This process continues all the way back to the RP (or until a router is reached that is already on the Shared Tree and therefore already has a (*, G) entry.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

35

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

36 36

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

36

PIM SM Registering
Senders begin sourcing Multicast Traffic
Senders dont necessarily perform IGMP group joins.

1st-hop router unicasts Registers to RP


A Mcast packet is encapsulated in each Register msg Registers messages follow unicast path to RP

RP receives Register messages


De-encapsulates Mcast packet inside Register msg Forwards Mcast packet down Shared Tree Sends (S,G) Join toward Source to build a SPT from the Source to the RP
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

37 37

All Senders are not necessarily Receivers and vice versa.


It is not a requirement that all sources be receivers. In the case of a source-only host, it is permissible for the host to simply begin sending multicast traffic without ever joining the group via IGMP.

1st-hop router sends Registers to the RP


In PIM Sparse mode, when a 1st-hop router receives the first multicast packet from directly connected source S for group G, it creates (S, G) state and sets the F bit in the (S, G) entry to indicate that it is a directly connected Source and also sets the Registering flag to indicate that its in the process of Registering. Next, the 1st-hop router encapsulates the original multicast packet in a PIM Register message and unicasts it to the RP. (Any subsequent multicast packets received from directly connected source S for group G are also encapsulated in a Register message and unicast to the RP. This continues until an (S, G) Register-Stop message is received from the RP.)

RP receives Register messages


When the RP receives a Register message it will de-encapsulated the message. If this packet is to a Group for which the RP has (*, G) state, the RP will: Forward the original packet out all interfaces in the the (*, G) entrys oilist. If it hasnt already done so, the RP creates (S, G) state and sends an (S, G) Join back towards the Source in order to join the Shortest-path Tree (SPT) to Source S.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

37

PIM SM Registering (cont.)


1st-hop router receives (S,G) Join
SPT between Source and RP is now built. Begins forwarding traffic down SPT to RP (S,G) Traffic temporarily flowing down 2 paths to RP

RP receives traffic down native SPT


Sends a Register-Stop msg to the 1st-Hop router.

1st-hop router receives Register-Stop


Stops encapsulating traffic in Register messages (S,G) Traffic now flowing down single SPT to RP

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

38 38

1st-hop router receives (S, G) Join


When the 1st-hop router receives the (S, G) Join (sent hop-by-hop from the RP), it processes it normally by adding the interface, from which the Join was received, to the oilist of the existing (S, G) entry. (This entry was originally created when the 1st-hop router received the first multicast packet from directly connected Source S.) This completes the building of the Shortest-Path Tree (SPT) from the Source to the RP. The 1st-hop router now begins forwarding Source S multicast traffic down the newly built Shortest-Path Tree (SPT) to the RP. Note: (S, G) traffic temporarily flows to the RP via two methods; via Register messages (until a Register-Stop message is received) and the native ShortestPath Tree (SPT).

RP begins receiving traffic down the (S, G) SPT.


As soon as the RP begins receiving (S, G) traffic natively (I.e. not encapsulated in Register messages) down the SPT, the RP will set the T bit in the (S, G) entry to denote that traffic is succesfully flowing down the ShortestPath Tree (SPT). Now when any (S, G) Register messages are received by the RP, it sees that the T bit is set in the (S, G) entry will respond by sending a PIM (S, G) Register-Stop message to the 1st-hop router. This notifies the 1st-hop router that traffic is now being received natively down the SPT.

1st-hop router receives Register-Stop message


When the (S, G) Register-Stop message is received by the 1st-hop router, it clears the Registering flag in the (S, G) entry and stops encapsulating (S,G) traffic in Register messages. Traffic is now flowing only down the SPT to the RP.
Copyright ? ?1999-2001, Cisco Systems, Inc.
Module5.ppt

38

PIM SM Register Examples

Receivers Join Group First Source Registers First Receivers along the SPT

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

39 39

PIM SM Register Examples


Depending on whether there are any existing Receivers for group G on the Shared Tree (RPT), the RP hands the Register process a little different. In the following examples we will consider the Register process for the cases when: Receivers join group G first; The Source Registers first. Receivers along the SPT.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

39

PIM SM Registering
Receiver Joins Group First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

Shared Tree

(*, 224.1.1.1), 00:03:14/00:02:59, RP 171.68.28.140, flags:S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:03:14/00:02:45 Serial1, Forward/Sparse, 00:03:14/00:02:45

State in RP before any source registers


(with receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

40 40

State in RP before Registering (Rcvrs on Shared Tree)


Pay particular attention to the following in the (*, G) entry: The Incoming interface: is NULL and the RPF nbr is 0.0.0.0. This indicates that this router is the RP. The Outgoing interface list: contains Serial0 and Serial1 which are assumed to be the only two active branches of the Shared Tree (RPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

40

PIM SM Registering
Receiver Joins Group First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

Shared Tree

rtr-b rtr-b>sh >sh ip ip mroute mroute 224.1.1.1 224.1.1.1 No No such such group group

State in rtr-b before any source registers


(with receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

41 41

State in rtr-b before source registers


Note that there is no group state information for this Group yet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

41

PIM SM Registering
Receiver Joins Group First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

Shared Tree

rtr-a >sh ip mroute 224.1.1.1 No such group.

State in rtr-a before any source registers


(with receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

42 42

State in 1st-hop router (rtr-a) before source registers


Note that there is no group state information for this Group yet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

42

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets

1
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

RP

rtr-a

rtr-b

rtr-c

Shared Tree

Source begins sending group G traffic.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

43 43

Receivers Join Group First Example


1) Source S begins sending traffic to group G. 2) 1st-hop router (rtr-a) creates (*, G) and (S, G) state; encapsulates the multicast packets in PIM Register message(s) and unicasts it(them) to the RP. 3) The RP (rtr-c) de-encapsulates the packets and sees that the packet is for group G for which it already has (*, G) state. It then forwards the packets down the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

43

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets

Register Msgs RP

Source 171.68.37.121

E0

S0

S0

S1

S3 S0 S1

rtr-a

rtr-b

rtr-c

Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null PT (171.68.37.121/32, FPT (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, flags: flags: F FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Outgoing Outgoing interface interface list: list: Null Null

rtr-a creates (S, G) state for source


(After automatically creating a (*, G) entry)
1 2

Source begins sending group G traffic. rtr-a encapsulates packets in Registers; unicasts to RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

44 44

1st-hop router (rtr-a) creates (S, G) state


A (*, G) entry must be created before the (S, G) entry can be created. Note that: The RPF information for this entry points up the Shared Tree via Serial0 with the RPF neighbor of 171.68.28.191. (Serial 0 of rtr-b.) Because in this example no members have joined the group (the sender is only sending), the OIL of the (*, G) entry is Null. The P flag (Pruned) is set since the OIL is Null. The (S, G) entry is then created. Pay particular attention to the following: The RPF information for this entry points towards the source via Ethernet0. The RPF neighbor is 0.0.0.0 because the source is directly connected. The (S, G) OIL receives a copy of the (*, G) OIL. (Which is Null.) The F flags are set in the (S, G) entry which indicates that this is a directly connected Source. The Registering flag is set in the (S, G) entry which indicates that we are still sending Register messages to the RP for this Source. The P flag (Pruned) is set since the OIL is Null. 2) The 1st-hop router encapsulates the multicast packets in PIM Register message(s) and unicasts them to the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

44

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs 171.68.28.139
S0 S3 S0 S1

RP

Source 171.68.37.121

E0

S0

S1

rtr-a

rtr-b

rtr-c

3 (*, 224.1.1.1)
Mcast Traffic Shared Tree

(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:09:21/00:02:38 Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121, 224.1.1.1, 00:01:15/00:02:46, flags: Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial0, Forward/Sparse, 00:00:49/00:02:11 Serial1, Forward/Sparse, 00:00:49/00:02:11

RP processes Register; creates (S, G) state


3

rtr-c (RP) de-encapsulates packets; forwards down Shared tree.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

45 45

The RP creates (S, G) state


As a result of the Register message that was received from rtr-a, the RP creates (S, G) state as follows: The RPF information is calculated using the source address contained in the multicast packet encapsulated inside of the register message. This results in an IIF of Serial3 and an RPF neighbor of 171.68.28.139. Next, the OIL of the parent (*, G) entry is copied into the OIL of the new (S,G) entry. (An additional check is made to insure that the IIF does not appear in the OIL. If it does, it is removed to prevent a route loop.) Now the router is ready to forward the (S, G) packet that was encapsulated in the Register message using the newly created (S, G) state. (Note that traffic is always forwarded using the matching (S, G) entry if one exists. Otherwise, the (*, G) entry is used.) This is accomplished as follows: Because this packet was received inside of a Register message, the RPF check is skipped. Next, the router forwards a copy of the packet out all interfaces in the (S, G) OIL. In this case a copy is sent out Serial0 and Serial1 which corresponds to the two branches of the Shared Tree. The T flag is not yet set in the (S, G) entry. However, when the first (S, G) packet is received natively (via the Incoming interface) and forwarded using this entry, the T flag will be set.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

45

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs (S,G) Join

4 S0
S0 S1

RP

Source 171.68.37.121

E0

S0

S0

S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree

RP sends (S,G) Join toward Source to build SPT.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

46 46

Receivers Join Group First Example (cont.)


4) Because RP has existing (*, G) state (I.e. Receivers already waiting on the Shared Tree), it sends an (S, G) Join toward source S to build a Shortest-Path Tree (SPT) from source S to the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

46

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets (S,G) Join Source 171.68.37.121
E0 S0

Register Msgs

5 S0
S0 S1 S0 S1

RP

rtr-a 171.68.28.190

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null

RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP nbr nbr 171.68.28.140, 171.68.28.140,

(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

rtr-b processes Join, creates (S, G) state


(After automatically creating the (*, G) entry) 5

rtr-b sends (S,G) Join toward Source to continue building SPT.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

47 47

rtr-b processes the (S, G) Join and creates state


A (*, G) entry must be created before the (S, G) entry can be created. Note that: The RPF information for the (*, G) entry points up the Shared Tr ee via Serial1 with the RPF neighbor of 171.68.28.140. (Serial 3 of the RP.) Because in this example no members have joined the group, the OIL of the (*, G) entry is Null. The P flag (Pruned) is set since the OIL is Null. The (S, G) entry is then created. Pay particular attention to the following: The RPF information for this entry points towards the source via Serial0. The RPF neighbor is 171.68.28.190. (Serial 0 of rtr-a.) The (S, G) OIL initially receives a copy of the (*, G) OIL. (Which is Null.) Interface Serial1 (which is the interface that received the (S, G) Join) is added to the (S, G) OIL. The T flag is not yet set in the (S, G) entry. However, when the first (S, G) packet is forwarded using this entry, the flag will be T set. 5) Because the OIL of the (S, G) transitioned from Null to non-Null (when rtr-b added Serial1 to the OIL of the newly created entry), a PIM (S, G) Join is sent to rtr-as to continue the process of joining the SPT.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

47

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs RP Source 171.68.37.121
E0 S0 S0 S1 S0 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Registering Outgoing Outgoing interface interface list: list: Serial0, Forward/Sparse, 00:04:28/00:01:32

rtr-a processes the (S, G) Join; adds Serial 0 to OIL

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

48 48

rtr-a processes the (S, G) Join


Because an (S, G) entry already existed, rtr-a simply added the interface on which it received the (S, G) join to the OIL. This results in the following: Serial0 is now listed in the Outgoing interface list (OIL) since the RP joined the SPT via this interface. The P flag (Pruned) is cleared since the OIL is no longer Null.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

48

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs

6
Source 171.68.37.121
E0 S0 S0 S1 S0 S1

RP

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

7 Register -Stop

Shared Tree

6 7

RP begins receiving (S,G) traffic down SPT. RP sends Register-Stop to rtr-a.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

49 49

A branch of the (S,G) SPT has been built to the RP.


6) Now that the SPT has been built from source S to the RP, traffic begins flowing down the Shortest-Path Tree (SPT). At this point, the RP is receiving the (S, G) traffic natively down the SPT. (This causes the T flags to be set in the (S, G) entries along this path including in the RP.) 7) The RP then sends an (S, G) Register-Stop to the 1st-hop router to inform it that the encapsulated group G Register messages from source S are no longer necessary.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

49

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets

8
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

RP

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Registering Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

rtr-a stops sending Register messages


(Final State in rtr-a)
8

(S,G) Traffic now flowing down a single path (SPT) to RP.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

50 50

rtr-a stops sending Register messages


When the 1st-hop router (rtr-a) receives the (S, G) Register-Stop message it ceases sending encapsulated Register messages for (S, G) traffic. Notice that the Registering flag on the second line of the (S, G) entry is no longer being displayed indicating that rtr-a is not sending Registers. This is the final state in rtr-a after the Registration process. 8) (S, G) traffic is now only flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

50

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S0 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null

RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP nbr nbr 171.68.28.140, 171.68.28.140,

(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

Final state in rtr-b

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

51 51

Final state in rtr-b after the Registration process


Pay particular attention to the following in the (S, G) entry: The T flag is now set indicating that (S, G) traffic is flowing along this path. The (*, G) entry still has a Null OIL and the P flag is still set. This is because there are no members that have joined the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

51

PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree (*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:09:21/00:02:38 Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial0, Forward/Sparse, 00:00:49/00:02:11 Serial1, Forward/Sparse, 00:00:49/00:02:11

Final state in the RP


(with receivers on Shared Tree)
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

52 52

Final state in the RP after the Registration process


Pay particular attention to the following in the newly created (S, G) entry: The T flag is now set indicating that (S, G) traffic is flowing along this path.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

52

PIM SM Register Examples

Receivers Join Group First Source Registers First Receivers along the SPT

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

53 53

PIM SM Register Examples


Depending on whether there are any existing Receivers for group G on the Shared Tree (RPT), the RP hands the Register process a little different. In the following examples we will consider the Register process for the cases when: Receivers join group G first; The Source Registers first.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

53

PIM SM Registering
Source Registers First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

rtr-c rtr-c>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.

State in RP before Registering


(without receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

54 54

State in RP before Registering (w/o Rcvrs on Shared Tree)


Notice that no state for group G exists since there are no Receivers on the Shared Tree yet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

54

PIM SM Registering
Source Registers First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

rtr-b rtr-b>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.

State in rtr-b before any source registers


(with receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

55 55

State in rtr-b before source registers


Note that there is no group state information for this Group yet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

55

PIM SM Registering
Source Registers First

RP
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

rtr-a >show ip mroute 224.1.1.1 Group 224.1.1.1 not found.

State in rtr-a before any source registers


(with receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

56 56

State in 1st-hop router (rtr-a) before source registers


Note that there is no group state information for this Group yet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

56

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets

1
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

RP

rtr-a

rtr-b

rtr-c

Source begins sending group G traffic.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

57 57

Source Registers First Example


1) Source S begins sending traffic to group G. 2) 1st-hop router (rtr-a) creates (*, G) and (S, G) state; encapsulates the multicast packets in PIM Register message(s) and unicasts it(them) to the RP. 3) The RP (rtr-c) de-encapsulates the (S, G) packet and creates (*, G) and (S, G) state. Since no one has joined the Shared Tree yet, the OILs of these entries will be NULL.. Because the OIL of the (S, G) entry (just created) is NULL, the packet is discarded.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

57

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets

2 Register Msgs
RP

Source 171.68.37.121

E0

S0

S0

S1

S3 S0 S1

rtr-a

rtr-b

rtr-c

(*, (*, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null PT (171.68.37.121/32, FPT (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, flags: flags: F FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Outgoing Outgoing interface interface list: list: Null Null

rtr-a creates (S, G) state for source


(After automatically creating a (*, G) entry)
1 2

Source begins sending group G traffic. rtr-a encapsulates packets in Registers; unicasts to RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

58 58

1st-hop router (rtr-a) creates (S, G) state


A (*, G) entry must be created before the (S, G) entry can be created. Note that: The RPF information for this entry points up the Shared Tree via Serial0 with the RPF neighbor of 171.68.28.191. (Serial 0 of rtr-b.) Because in this example no members have joined the group (the sender is only sending), the OIL of the (*, G) entry is Null. The P flag (Pruned) is set since the OIL is Null. The (S, G) entry is then created. Pay particular attention to the following: The RPF information for this entry points towards the source via Ethernet0. The RPF neighbor is 0.0.0.0 because the source is directly connected. The (S, G) OIL receives a copy of the (*, G) OIL. (Which is Null.) The F flags are set in the (S, G) entry which indicates that this is a directly connected Source. The Registering flag is set in the (S, G) entry which indicates that we are still sending Register messages to the RP for this Source. The P flag (Pruned) is set since the OIL is Null. 2) The 1st-hop router encapsulates the multicast packets in PIM Register message(s) and unicasts them to the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

58

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs 171.68.28.139
S0 S0 S1 S3 S0 S1

RP

Source 171.68.37.121

E0

3
rtr-c

rtr-a

rtr-b

(*, 224.1.1.1), 00:01:15/00:01:45, RP 171.68.28.140, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Null (171.68.37.121, 224.1.1.1), 00:01:15/00:01:45, flags: P Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Null

RP processes Register; creates (S, G) state


(After automatically creating the (*, G) entry) 3 rtr-c (RP) has no receivers on Shared Tree; discards packet.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

59 59

The RP creates (S, G) state


As a result of the Register message that was received from rtr-a, the RP creates (*, G) and (S, G) state. However, because no previous (*, G) state existed, it must be created before the (S,G) entry can be created. This (*, G) entry is created as shown above. Notice that the (*, G) OIL is NULL. This is because the RP has not yet received any (*, G) Joins for this group. (Remember, in this example, the source registers first.) Next, the (S, G) entry can be created and is accomplished as follows: The RPF information is calculated using the source address contained in the multicast packet encapsulated inside of the register message. This results in an IIF of Serial3 and an RPF neighbor of 171.68.28.139. Next, the OIL of the parent (*, G) entry is copied into the OIL of the new (S,G) entry. Since the OIL of the (*, G) entry is NULL, this results in a NULL (S, G) OIL. Now the router is ready to forward the (S, G) packet that was encapsulated in the Register message using the newly created (S, G) state. This is accomplished as follows: Because this packet was received inside of a Register message, the RPF check is skipped. Next, the router forwards a copy of the packet out all interfaces in the matching (S, G) OIL. However, because the (S, G) OIL is NULL (i.e. there are no branches of the Shared Tree), the packet is simply discarded.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

59

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b Register -Stop

rtr-c

RP sends Register-Stop to rtr-a.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

60 60

Source Registers First Example


4) Since the RP has no (*, G) state and hence no receivers on the Shared Tree, it does not need the (S, G) traffic. Therefore the RP sends an (S, G) RegisterStop message to the 1st-hop router so it will stop sending Register messages.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

60

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

rtr-a stops encapsulating traffic in Register Messages; drops packets from Source.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

61 61

Source Registers First Example


5)The 1st-hop router receives the (S, G) Register-Stop message and stops sending Register messages for (S, G) traffic. Note: Eventually, the original (S, G) entry will time out (approx. 3 min.) and be deleted. The Register process will start over again when the 1st-hop router receives the next multicast packet from directly connected source S. The RP will again respond with a Register-Stop which will prevent the (S,G) traffic from flowing to the RP until it is needed.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

61

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

(*, (*, 224.1.1.1), 224.1.1.1), 00:01:28/00:01:32, 00:01:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:28/00:01:32, 00:01:28/00:01:32, flags: flags: FPT FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Null Null

State in rtr-a after Registering


(without receivers on Shared Tree)
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

62 62

State in 1st-hop router after Registering (w/o Rcvrs on Shared Tree)


Pay particular attention to the following in the (S, G) entry: The Registering flag is now cleared. The Outgoing interface list is still Null since the RP did not join the SPT. The P flag (Pruned) is still set since the oilist is still Null. The 00:01:32 Expiration time value will count down to zero at which time the (S, G) entry will be deleted. (The Register process will begin all over again when the next multicast packet is received from source S.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

62

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

rtr-b rtr-b>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.

State in rtr-b after rtr-a Registers


(without receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

63 63

State in rtr-b after Registering (w/o Rcvrs on Shared Tree)


Notice that no state exists in rtr-b at this point in time.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

63

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

(*, (*, 224.1.1.1), 224.1.1.1), 00:01:15/00:01:45, 00:01:15/00:01:45, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121, (171.68.37.121, 224.1.1.1), 224.1.1.1), 00:01:15/00:01:45, 00:01:15/00:01:45, flags: flags: P P Incoming Incoming interface: interface: Serial3, Serial3, RPF RPF nbr nbr 171.68.28.139, 171.68.28.139, Outgoing Outgoing interface interface list: list: Null Null

State in RP after rtr-a Registers


(without receivers on Shared Tree)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

64 64

State in RP after Registering (w/o Rcvrs on Shared Tree)


Pay particular attention to the following in the newly created (S, G) entry: The RPF nbr is the IP Address of rtr-b. The Incoming interface: is Serial3 which is the RPF interface towards source S via rtr-b. The Outgoing interface list: is Null since the (*,G) OIL is also Null. (Indicates there are no Receivers on the Shared Tree yet.) The P flag (Pruned) is set since the OIL is Null. The (S,G) state will remain in the RP as long as the source is still actively sending. This is accomplished by fact that the first-hop route will continue sending periodic Register messages to the RP as long as the first-hop router is receiving traffic from the source.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

64

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c

(*, G) Join

Receivers begin joining the Shared Tree

RP (rtr-c) receives (*, G) Join from a receiver on Shared Tree.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

65 65

Source Registers First Example


6)The RP now begins receiving (*, G) Joins from Last-hop routers with Receivers that wish to join the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

65

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets

7
(S, G) Join RP
S0 S0 S1 S3 S0 S1

Source 171.68.37.121

E0

rtr-a

rtr-b

rtr-c

(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:00:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:14/00:02:46

RP processes (*,G) Join


(Adds Serial1 to Outgoing Interface Lists)
7

RP sends (S,G) Joins for all known Sources in Group.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

66 66

The RP process the (*, G) Join


In the (*, G) entry: Serial1 has been added to the (*, G) entry since a (*,G) Join was received on this interface which is the only active branch of the Shared Tree (RPT). In the (S, G) entry: Serial1 has also been added to the (S, G) OIL because the OILs of all (S,G) entries are always kept in sync with their parent (*, G). Note: When the (S, G) OILs are synchronized with the OIL of their parent (*,G) OIL, a check is made to insure that the IIF of the (S, G) does not appear in the OIL of the (S, G). This could result in a route loop. 7) The transitioning of the (*, G) OIL from Null to non-Null triggers the RP to scan its list of (S, G) entries for group G and send (S, G) Joins towards all sources. (This will cause a SPT to be built from each active source back to the RP which will eventually start the flow of (S, G) traffic to the RP.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

66

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets

8
(S, G) Join RP
S1 S3 S0 S1 S0 S0

Source 171.68.37.121

E0

rtr-a 171.68.28.190

rtr-b

rtr-c

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null

RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP nbr nbr 171.68.28.140, 171.68.28.140,

(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

rtr-b processes Join, creates (S, G) state


(After automatically creating the (*, G) entry) 8

rtr-b sends (S,G) Join toward Source to continue building SPT.


1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

67 67

rtr-b processes the (S, G) Join and creates state


A (*, G) entry must be created before the (S, G) entry can be created. Note that: The RPF information for the (*, G) entry points up the Shared Tr ee via Serial1 with the RPF neighbor of 171.68.28.140. (Serial 3 of the RP.) Because in this example no members have joined the group, the OIL of the (*, G) entry is Null. The P flag (Pruned) is set since the OIL is Null. The (S, G) entry is then created. Pay particular attention to the following: The RPF information for this entry points towards the source via Serial0. The RPF neighbor is 171.68.28.190. (Serial 0 of rtr-a.) The (S, G) OIL initially receives a copy of the (*, G) OIL. (Which is Null.) Interface Serial1 (which is the interface that received the (S, G) Join) is added to the (S, G) OIL. The T flag is not yet set in the (S, G) entry. However, when the first (S, G) packet is forwarded using this entry, the flag will be T set. 8) Because the OIL of the (S, G) transitioned from Null to non-Null (when rtr-b added Serial1 to the OIL of the newly created entry), a PIM (S, G) Join is sent to rtr-as to continue the process of joining the SPT.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

67

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets

9
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

RP

rtr-a

rtr-b

rtr-c

10 (*, 224.1.1.1)
Mcast Traffic

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Outgoing Outgoing interface interface list: list: Serial0, Forward/Sparse, 00:04:28/00:01:32

rtr-a processes the (S, G) Join; adds Serial0 to OIL


9 RP begins receiving (S,G) traffic down SPT. 10 RP forwards (S,G) traffic down Shared Tree to receivers.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

68 68

1st-hop router (rtr-a) processes the (S, G) Join


The (S, G) Join is processed as follows: Serial0 is added to the Outgoing interface list (OIL). (This is the interface on which the (S, G) Join arrived.) The P flag (Pruned) is cleared since the OIL is no longer Null. 9) As a result of Serial0 being added to the (S, G) OIL, traffic begins to flow down the SPT from the source to the RP. 10) The RP then forwards all incoming (S, G) traffic to the Receivers down the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

68

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a 171.68.28.190

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 171.68.28.140, 171.68.28.140, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

Final state in rtr-b after Receivers Join


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

69 69

State in rtr-b after Receivers Join


Pay particular attention to the following: Both (*, G) and (S, G) state was created as a result of the (S, G) Join received from the RP. The P flag set in the (*, G) entry since there are no receivers on the Shared Tree at this point in the network. The T flag is set in the (S, G) entry indicating that traffic is flowing down the Shortest-Path Tree. The RPF nbr is the IP Address of rtr-a. Serial0 is the Incoming interface of the (S, G) entry since this is the RPF interface for source S via rtr-a. Serial1 is listed in the Outgoing interface list of the (S, G) entry since the RP joined the SPT via this interface.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

69

PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11

Final state in RP after Receivers Join

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

70 70

State in RP after Receivers Join


In the (*, G) entry: Serial1 has been added to the (*, G) entry since a (*,G) Join was received on this interface which is the only active branch of the Shared Tree (RPT). In the (S, G) entry: Serial1 has also been added to the (S, G) OIL because the OILs of all (S,G) entries are always kept in sync with their parent (*, G). Note: When the (S, G) OILs are synchronized with the OIL of their parent (*, G) OIL, a check is made to insure that the IIF of the (S, G) does not appear in the OIL of the (S, G). This could result in a route loop.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

70

PIM SM Register Examples

Receivers Join Group First Source Registers First Receivers along the SPT

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

71 71

PIM SM Register Examples


Depending on whether there are any existing Receivers for group G on the Shared Tree (RPT), the RP hands the Register process a little different. In the following examples we will consider the Register process for the cases when: Receivers join group G first; The Source Registers first. Receivers along the SPT.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

71

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 171.68.28.140, 171.68.28.140, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32

Current state in rtr-b


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

72 72

State in rtr-b with traffic flowing on the SPT


Pay particular attention to the following: Both (*, G) and (S, G) state was created as a result of the (S, G) Join received from the RP. The P flag set in the (*, G) entry since there are no receivers on the Shared Tree at this point in the network. The T flag is set in the (S, G) entry indicating that traffic is flowing down the Shortest-Path Tree. The RPF nbr is the IP Address of rtr-a. Serial0 is the Incoming interface of the (S, G) entry since this is the RPF interface for source S via rtr-a. Serial1 is listed in the Outgoing interface list of the (S, G) entry since the RP joined the SPT via this interface.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

72

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11

Current state in the RP


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

73 73

State in the RP with traffic flowing on the SPT


Pay particular attention to the following: The (*, G) entry only has Serial1 in its outgoing interface list. In the (S, G) entry, Serial0 is the Incoming interface since this is the RPF interface for source S via rtr-b. Serial1 is listed in the Outgoing interface list of the (S, G) entry because the OIL of the (S, G) entry is always kept in sync with the (*, G) OIL.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

73

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

1 IGMP Join
Rcvr A

Rcvr A wishes to receive group G traffic. Sends IGMP Join for G.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

74 74

Receivers along the SPT


Step 1: A host directly connected to rtr-b, Receiver A, joins multicast group 224.1.1.1 by sending an IGMP Report.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

74

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Rcvr A (*, 224.1.1.1), 00:04:28/00:01:32, RP 171.68.28.140, flags: SC Incoming interface: Serial1, RPF nbr 171.68.28.140, Outgoing interface list: Ethernet0, Forward/Sparse, 00:00:30/00:02:30 (171.68.37.121/32, 224.1.1.1), 00:04:28/00:01:32, flags: CT Incoming interface: Serial0, RPF nbr 171.68.28.190 Outgoing interface list: Serial1, Forward/Sparse, 00:04:28/00:01:32 Ethernet0, Forward/Sparse, 00:00:30/00:02:30

Added Interfaces

State in rtr-b after Rcvr A joins group


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

75 75

Receivers along the SPT


As a result of the IGMP Report sent by Receiver A for group 224.1.1.1, rtr-b updates its state for this group as follows. Ethernet0 is added to the OIL of the (*, G) entry. This is done to permit any (*, 224.1.1.1) traffic flowing down the Shared Tree to be forwarded to Receiver A. Next, the OILs of all child (S, G) entries are synchronized with the OIL change just made to the OIL of the (*, G). This results in Ethernet0 being added to the OIL of the (171.68.37.121/32, 224.1.1.1) entry. This permits traffic from this source to be picked off as it flows along the SPT through rtr-b on its way to the RP. (Note that this traffic does not flow to the RP and then back out the same interface to reach rtr-b. This is a common misperception.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

75

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0

rtr-a

rtr-b

S3 S1

rtr-c (*, 224.1.1.1) Mcast Traffic

(*, G) Join

Rcvr A

rtr-b triggers a (*,G) Join to join the Shared Tree

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

76 76

Receivers along the SPT


Step 2: Because the OIL of the (*, G) entry in rtr-b transitioned from NULL to non-Null (Ethernet0 is now in the (*, G) OIL), a (*, G) Join message is triggered. This message is sent up the Shared Tree so that rtr-b will be placed on a branch of the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

76

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

Rcvr A (*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 Serial3, Forward/Sparse, 00:00:10/00:02:50 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11

State in RP after rtr-b joins Shared Tree


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

77 77

Receivers along the SPT


When the RP receives the (*, G) Join sent by rtr-b, it adds Serial3 to the (*, G) OIL. Next, the RP synchronizes the OILs of all (S, G) entries by adding Serial3 to each (S, G) OIL. However in this case, Serial3 is the Incoming interface for the (171.68.37.121/32, 224.1.1.1) entry and is therefore not added to the OIL. (If it were, Serial3 would appear in both the incoming and outgoing interface list which could cause a route loop.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

77

PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1

rtr-a

rtr-b

rtr-c (*, 224.1.1.1) Mcast Traffic

3
Rcvr A

Group G traffic begins to flow to Rcvr A.


(Note: 171.68.37.121 traffic doesnt flow to RP then back down to rtr-b)
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

78 78

Receivers along the SPT


Step 3: Traffic from source 171.68.37.121 is now being picked off by rtr-b and forwarded out Ethernet0 as the traffic flows down the SPT to the RP. Again, it is important to note that this source traffic does not flow to the RP and then turn around and come back out on the same interface that it arrived. (Refer to the state in the RP shown on the previous page.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

78

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

79 79

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

79

PIM SM SPT-Switchover
SPT Thresholds may be set for any Group
Access Lists may be used to specify which Groups Default Threshold = 0kbps (I.e. immediately join SPT) Threshold = infinity means never join SPT.

Threshold triggers Join of Source Tree


Sends an (S,G) Join up SPT for next S in G packet received.

Pros
Reduces Network Latency

Cons
More (S,G) state must be stored in the routers.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

80 80

SPT Thresholds
In PIM Sparse mode, SPT Thresholds may be configured to control when to switch to the Shortest-Path Tree (SPT). SPT Thresholds are specified in Kbps and can be used with Access List to specify to which Group(s) the Threshold applies. The default SPT-Threshold is 0Kbps. This means that any and all sources are immediately switched to the Shortest-Path Tree. If an SPT-Threshold of Infinity is specified for a group, the sources will not be switched to the Shortest-Path Tree (SPT) and will remain on the Shared Tree.

Exceeding the Threshold


When the Groups SPT-Threshold is exceed in a last-hop router, the next received packet for the group will cause an (S, G) Join to be sent toward the source of the packet. This builds a Shortest-Path Tree from the source S to the last-hop router.

PROS
By switching to the Shortest-Path Tree (SPT), the most optimal (usually) path is used to deliver the multicast traffic. Depending on the location of the source in relation to the RP, this switch to the SPT can reduce network latency substantially.

CONS
In networks with large numbers of senders (remember most multicast applications such as IP/TV Client, send RTCP multicast packets in the background and are therefore senders), an increased amount of state must be kept in the routers. In some cases, an Infinity threshold may be used to force certain groups to remain on the Shared Tree when latency is not an issue.
Copyright ? ?1999-2001, Cisco Systems, Inc.
Module5.ppt

80

PIM SM SPT-Switchover
SPT-Switchover Mechanism
Once Once each each second second

Compute Compute new new (*, (*, G) G) traffic traffic rate rate If If threshold threshold exceeded, exceeded, set set J J flag flag in in (*, (*, G) G)
For For each each (S (Sii,, G) G) packet packet received: received:

If If J J flag flag set set in in (*, (*, G) G)


Join Join SPT SPT for for (S (Sii ,, G) G) Mark Mark (S (Sii ,, G) G) entry entry with with J J flag flag Clear Clear J J flag flag in in (*,G) (*,G)

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

81 81

SPT-Threshold Myth
This is a frequently misunderstood mechanism. Many people think that the the traffic rates of the sources in the group are monitored and compared against the SPT-Threshold. THIS IS NOT THE CASE. Instead, the total aggregate rate of Group traffic flowing down the Shared Tree (RPT) is calculated once per second. If this total aggregate rate is exceed, then the next Group packet received causes that source to be switched to the Shortest-Path Tree (SPT).

SPT-Switchover Mechanism
Once each second, the aggregate (*, G) traffic rate is computed and checked against the SPT-Threshold. If the aggregate rate of all group traffic flowing down the Shared Tree (RPT) exceeds the threshold, then the J flag is set in the (*, G) entry. As each multicast packet is received on the Shared Tree, the J bit is checked in the (*, G) entry. If the J flag is set, a new (S, G) entry is created for the source of the packet. An (S, G) Join is sent towards the source in order to join the SPT. The J flag is set in the (S, G) entry to denote that this entry was created as a result of the SPT-Threshold switchover. The J flag in the (*, G) is reset. (It will be set in one second if the aggregate rate on the Shared Tree is still over the SPT-Threshold.) This mechanism can sometimes result in low rate sources being switched to the SPT erroneously. However, the RPT-switchback mechanism will correct this situation and eventually only the high rate sources will be received via SPTs while low rate sources will remain on the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

81

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.5.1, Outgoing interface list: Serial1, Forward/Sparse, 00:01:43/00:02:11 Serial2, Forward/Sparse, 00:00:32/00:02:28

State in rtr-c before switch


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

82 82

PIM-SM SPT-Switchover Example


Receivers A & B have joined multicast group 224.1.1.1 which has resulted in traffic flowing down the Shared Tree as shown by the solid arrows. The state is rtr-c prior to the switchover is as follows: The IIF of the (*, G) entry points toward the RP via Serial0. The OIL of the (*, G) entry contains Serial1 and Serial2 as a result of (*, G) Joins that were sent up the Shared Tree by rtr-a and rtr-d, respectively.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

82

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Serial0, RPF nbr 10.1.4.8, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11

State in rtr-d before switch


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

83 83

PIM-SM SPT-Switchover Example


The state is rtr-d prior to the switchover is as follows: The IIF of the (*, G) entry points toward the RP via Serial0. The OIL of the (*, G) entry contains Ethernet0 as a result of the IGMP Reports for group 224.1.1.1 that are sent by Receiver B.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

83

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11

State in rtr-a before switch


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

84 84

PIM-SM SPT-Switchover Example


The state is rtr-a prior to the switchover is as follows: The IIF of the (*, G) entry points toward the RP via Serial0. The OIL of the (*, G) entry contains Ethernet0 as a result of (*, G) Joins that were sent up the Shared Tree by rtr-b.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

84

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11

State in rtr-b before switch


85 85

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

PIM-SM SPT-Switchover Example


The state is rtr-b prior to the switchover is as follows: The IIF of the (*, G) entry points toward the RP via Ethernet0. The OIL of the (*, G) entry contains Ethernet1 as a result of the IGMP Reports for group 224.1.1.1 that are sent by Receiver A.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

85

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1 1 Group G rate > Threshold

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11

1 2

Group G rate exceeds SPT Threshold at rtr-b; Set J Flag in (*, G) and wait for next (Si,G) packet.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

86 86

PIM-SM SPT-Switchover Example


Step 1: The total amount of all traffic flowing down the Shared Tree begins to exceed the SPT-Threshold configured at rtr-b. Step 2: As a result, rtr-b sets the J flag in the (*, G) entry to denote that the rate is above the SPT-Threshold for this group.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

86

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1 3

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11

3 4

(Si,G) packet arrives down Shared tree. Clear J Flag in the (*,G) & create (Si,G) state.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

87 87

PIM-SM SPT-Switchover Example


Step 3: The very next packet to arrive via the Shared Tree happens to be from source (Si, G). Because there is a member directly connected to this router (denoted by the C flag) and the traffic rate is above the SPT-Threshold (denoted by the J flag), rtr-b initiates a switch to the SPT for (Si, G) traffic. Step 4: The J flag in the (*, G) entry is first cleared and an new traffic rate measurement interval (1 second) is started. Next, (Si, G) state is created for source Si sending to group G.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

87

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:00:28/00:02:51, flags: C CJT JT Incoming interface: Ethernet0, RPF nbr 10.1.2.1 Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:28/00:02:32

J Flag indicates (S, G) created by exceeding the SPT-threshold

New State in rtr-b


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

88 88

PIM-SM SPT-Switchover Example


The (171.68.37.121/32, 224.1.1.1) entry shown above is created as follows: To denote that this entry was created as a result of the SPT Switchover mechanism, the J flag is set on the (S, G) entry. (The J flag being set will cause rtr-b to monitor the rate of the (S, G) traffic and if the rate of this traffic drops below the SPT Threshold for over one minute, rtr-b will attempt to switch this traffic flow back to the Shared Tree.) The RPF information is calculated in the direction of source Si. This results in an Incoming interface of Ethernet0, and an RPF neighbor address of 10.1.2.1. . (Note: That the RPF information for the (S, G) entry is the same as the (*, G) entry. This indicates that the Shared Tree and the SPT are following the same path at this point.) The OIL for the (S, G) entry is constructed by copying the OIL from the (*, G) entry and then removing the IIF from this list to prevent a possible route loop. This results in an (S, G) OIL containing only Ethernet1.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

88

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1 5 (Si,G) Join

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

Send (Si,G) Join towards Si .

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

89 89

PIM-SM SPT-Switchover Example


Step 5: Once state has been created for (Si, G), an (S, G) Join is sent toward source Si to build a branch of the SPT to rtr-b. These (Si, G) Joins will continue to be sent periodically (once a minute) as long as the (Si, G) entry is not Pruned (i.e. does not have a Null OIL).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

89

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

Rcvr B (*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:13:28/00:02:53, flags: T Incoming interface: Serial1, RPF nbr 10.1.9.2 Outgoing interface list: Ethernet0, Forward/Sparse, 00:13:25/00:02:30

New state in rtr-a


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

90 90

PIM-SM SPT-Switchover Example


When the (Si, G) Join is received by rtr-a, the (171.68.37.121/32, 224.1.1.1) entry shown above is created as follows: The RPF information is calculated in the direction of source Si. This results in an Incoming interface of Serial1, and an RPF neighbor address of 10.1.9.1. . (Note: That the RPF information for the (S, G) entry is not the same as the (*, G) entry. This indicates that the paths of the Shared Tree and the SPT diverge at this point.) The OIL for the (S, G) entry is constructed by copying the OIL from the (*, G) entry and then removing the IIF from this list to prevent a possible route loop. This results in an (S, G) OIL containing only Ethernet0.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

90

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si 6 (Si ,G) Join

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

rtr-a forwards (Si,G) Join toward Si.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

91 91

PIM-SM SPT-Switchover Example


Step 6: When the (Si, G) state is created at rtr-a, an (Si, G) Join is sent toward source Si. These (Si, G) Joins will continue to be sent periodically (once a minute) as long as the (Si, G) entry is not Pruned (i.e. does not have a Null OIL).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

91

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si 7 (S ,G) Traffic i

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

6 7

rtr-a forwards (Si,G) Join toward Si. (Si, G) traffic begins flowing down SPT tree.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

92 92

PIM-SM SPT-Switchover Example


Step 7: When the (Si, G) Joins reach the first-hop router directly connected to source Si, a complete branch of the SPT has been built (shown by the dashed arrows). This permits (Si, G) traffic to flow via the SPT to rtr-b and receiver A.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

92

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1

(Si,G)RP-bit Prune

rtr-a

S1

To Source Si

S0
10.1.4.2

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

6 7 8

rtr-a forwards (Si,G) Join toward Si. (Si, G) traffic begins flowing down SPT tree. SPT & RPT diverge, triggering (Si,G)RP-bit Prunes toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

93 93

PIM-SM SPT-Switchover Example


Step 8: Because the paths of the Shared Tree and the SPT diverge at rtr-a, (note the difference in RPF information on the previous page), this causes rtr-a to begin sending (Si, G)RP-bit Prune messages up the Shared Tree to stop the flow of redundant (Si, G) traffic down the Shared Tree. (Note: This step is delayed until traffic begins arriving via the SPT which is denoted by the T flag being set in the (Si, G) entry in the mroute table.)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

93

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

Rcvr B (*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.5.1, Outgoing interface list: Serial1, Forward/Sparse, 00:01:43/00:02:11 Serial2, Forward/Sparse, 00:00:32/00:02:28 (171.68.37.121/32, 224.1.1.1), 00:13:28/00:02:53, flags: R Incoming interface: Serial0, RPF nbr 10.1.5.1 Outgoing interface list: Serial2, Forward/Sparse, 00:00:32/00:02:28

State in rtr-c after receiving the (Si, G) RP-bit Prune


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

94 94

PIM-SM SPT-Switchover Example


When the (Si, G)RP -bit Prune reaches rtr-c, the (171.68.37.121/32, 224.1.1.1) entry shown above is created as follows: Because this (S, G) entry was created as a result of the receipt of an (S,G)RP -bit Prune, the R bit is set to denote that this forwarding state is applicable to traffic flowing down the Shared Tree and not the Source Tree. Because the R bit is set, the RPF information is calculated in the direction of the RP instead of source Si. (Remember, this entry is applicable to (Si,G) traffic flowing down the Shared Tree and therefore the RPF information must point up the Shared Tree.) This results in an Incoming interface of Serial0, and an RPF neighbor address of 10.1.5.1. . The OIL for the (S, G) entry is constructed by copying the OIL from the (*, G) entry minus the interface that the (Si, G)RP-bit Prune was received. Next, the IIF is removed from the OIL to prevent a possible route loop. These steps results in an (S, G) OIL containing only Serial2. At this point, (Si, G) traffic flowing down the Shared Tree will be forwarded using the (Si, G) entry. (Si, G) traffic arriving at rtr-a will RPF correctly because the RPF information in the (Si, G) entry is pointing up the Shared Tree (as a result of the R bit) and will then be forwarded out all interfaces in the (Si, G) OIL. In this case, only Serial2 remains in the (Si, G) OIL and therefore (Si, G) traffic will be sent to rtr-d but not rtr-a. This successfully prunes the redundant (Si, G) traffic from the branch of the Shared Tree between rtr-c and rtr-a.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

94

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2

rtr-c
10.1.4.1

S1 9 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

S0

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

9 Unnecessary (S , G) traffic is pruned from the Shared tree. i

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

95 95

PIM-SM SPT-Switchover Example


Step 9: At this point, the redundant (Si, G) traffic is pruned from the Shared Tree branch from rtr-c to rtr-a. (Si, G) traffic is reaching receiver A via the SPT through rtr-a and rtr-b.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

95

PIM SM SPT-Switchover
To RP (10.1.5.1) S0 10 S0 S2

rtr-c
10.1.4.1

S1 S0
10.1.4.2

rtr-a

S1

To Source Si

E010.1.2.1

rtr-d
E0
Rcvr A Rcvr B

10.1.2.2

E0 E1

rtr-b

(Si, G) Traffic Flow Shared (RPT) Tree SPT Tree

9 Unnecessary (S , G) traffic is pruned from the Shared tree. i 10

(Si, G) traffic still flows via other branches of the Shared tree.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

96 96

PIM-SM SPT-Switchover Example


Step 10: (Si, G) traffic is still reaching receiver B via a branch of the Shared Tree through rtr-c and rtr-d. This is because the (Si, G) state in rtr-c still has Serial2 in its OIL.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

96

PIM SM SPT-Switchover
Shared Tree Switchback Mechanism
Once Once each each minute minute

If If J J flag flag set set in in (S (Sii,, G) G) entry entry


Compute Compute new new (S (Sii ,, G) G) traffic traffic rate rate If If rate rate < < SPT-threshold SPT-threshold
Rejoin Rejoin (*, (*, G) G) Tree Tree for for (S (S i i ,, G) G) traffic traffic Send Send(S (S i i,, G) G)prune pruneup upSPT SPTtoward toward S S ii Delete (S , G) entry Delete (S i i , G) entry

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

97 97

Shared Tree Switchback


The Shared Tree Switchback (for lack of a better term) mechanism is used to switch sources back to the Shared Tree when their traffic rate falls below the SPT-Threshold.

Switchback Algorithm
The Switchback mechanism runs once a minute. (This helps prevent Sources from cycling between Shared Tree and Shortest-Path Tree too rapidly.) For each (Si, G) entry in the Multicast Routing Table that has the J flag set, the mechanism computes the traffic rate for source Si. If the rate has fallen below the SPT-Threshold, a switchback to the Shared Tree is initiated by the last-hop router by: Sending a Join/Prune message that contains a (*, G) Join without a (Si, G)RP -bit Prune, up the Shared Tree (RPT). (This will cause the (Si, G) Prune state along the RPT to be deleted which will permit (Si, G) traffic to begin flowing down the RPT again.) Deleteing its (Si, G) entry in the Multicast Routing Table. Send (Si, G) Prune up the Shortest-Path Tree (SPT) to stop traffic from flowing down the SPT. Note that this Switchback Algorithm is broken in older versions of IOS.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

97

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

98 98

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

98

PIM SM Pruning

IGMP group times out / last host sends Leave Interface removed from all (*,G) & (S,G) entries
IF all interfaces in oilist for (*,G) are pruned; THEN send Prune up shared tree toward RP Any (S, G) state allowed to time -out

Each router along path prunes interface


IF all interfaces in oilist for (*,G) are pruned; THEN send Prune up shared tree toward RP Any (S, G) state allowed to time -out

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

99 99

SM Pruning
Locally connected host sends an IGMP Leave (or IGMP state times out in the router) for group G. The interface is removed from the (*, G) and all (S, G) entries in the Multicast Routing Table. If the (*, G) Outgoing Interface list is now Null, then send a (*, G) Prune up the Shared Tree (RPT) towards the RP. Any remaining (S, G) entries are allowed to timeout and be deleted from the Multicast Routing Table. When the routers up the Shared Tree receive the (*, G) Prune, they remove the interface on which the Prune was received from their (*, G) Outgoing interface list. If as a result of removing the interface the (*, G) Outgoing Interface list becomes Null, then forward a (*, G) Prune up the Shared Tree (RP T) towards the RP. Any remaining (S, G) entries are allowed to timeout and be deleted from the Multicast Routing Table.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

99

PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

S1

rtr-a
E0
10.1.2.1

10.1.2.2

E0

E1
Rcvr A

rtr-b

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11

State in rtr-b before Pruning


100 100

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

State in rtr-b before Pruning


Pay particular attention to the following: Traffic is flowing down the Shared Tree. (Denoted by the existance of only the (*, G) entry.) The Incoming interface is Ethernet0. The Outgoing interface list contains Ethernet1. The C flag is set in the (*, G) which denotes that there is a locally connected host for this group. (Rcvr A)

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

100

PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

S1

rtr-a
E0
10.1.2.1

10.1.2.2

E0

E1
Rcvr A

rtr-b

(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11

State in rtr-a before Pruning

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

101 101

State in rtr-a before Pruning RPT Case


Pay particular attention to the following: Traffic is flowing down the Shared Tree. (Denoted by the existance of only the (*, G) entry.) The Incoming interface is Serial0. The Outgoing interface list contains Ethernet0.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

101

PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

S1

rtr-a
E0
10.1.2.1

10.1.2.2

E0

3 (*,G) Prune

1 IGMP Leave
Rcvr A

E1 2

rtr-b

1 2 3

rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

102 102

PIM SM Pruning Example RPT Case


1) The last-hop or Leaf router (rtr-b) receives an IGMP Group Leave message from Rcvr A for group G. After performing the normal IGMP Leave processing and finding that Rcvr A was the last host to leave, the IGMP state for group G on interface E1 is deleted. 2) This causes interface E1 to be removed from the Outgoing interface list of the (*, G) entry and any (Si, G) entries (in this case there are none) in the Multicast Routing Table. Because E1 was the only interface in the (*, G) entry, its outgoing interface list becomes Null. 3) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is sent up the Shared Tree (RPT) via E0 toward the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

102

PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree

(*,G) Prune

X
E1

6 S0

S1

10.1.4.2

rtr-a

10.1.2.2

X
E0

E0 4

10.1.2.1

rtr-b

4 5 6

rtr-a receives Prune; removes E0 from (*,G) oilist.


(After the 3 second Multi-access Network Prune delay.)

rtr-a (*,G) oilist now empty; send (*,G) Prune toward RP. Pruning continues back toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

103 103

PIM SM Pruning Example RPT Case (cont.)


4) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 5) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 6) This pruning continues back toward the RP or until a router is reached whose (*, G) Outgoing interface list doesnt go to Null as a result of the Prune.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

103

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1
Rcvr A

rtr-b

(*, (*, 224.1.1.1), 224.1.1.1), 00:01:43/00:02:59, 00:01:43/00:02:59, RP RP 10.1.5.1, 10.1.5.1, flags: flags: SC SC Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1, 10.1.2.1, Outgoing Outgoing interface interface list: list: Ethernet1, Ethernet1, Forward/Sparse, Forward/Sparse, 00:01:43/00:02:11 00:01:43/00:02:11 (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:05/00:01:55, 00:01:05/00:01:55, flags: flags: CJT CJT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1 10.1.2.1 Outgoing Outgoing interface interface list: list: Ethernet1, Ethernet1, Forward/Sparse, Forward/Sparse, 00:01:05/00:02:55 00:01:05/00:02:55
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

State in rtr-b before Pruning

8/10/2001 2:37 PM

104 104

State in rtr-b before Pruning SPT Case


Pay particular attention to the following: Both a (*, G) and (S, G) entries exist. The J flag is set in the (S, G) entry. This indicates that the (S, G) state was created as a result of the SPT-Threshold being exceeded. The T flag is set in the (S, G) entry. This indicates that (S, G) traffic is being successfully received via the Shortest-Path Tree (SPT). The Incoming interface is the same for the (*, G) and the (S, G) entry. This indicates that Shared Tree and the Shortest-Path tree are the same at this point.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

104

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1
Rcvr A

rtr-b

(*, 224.1.1.1), 00:01:43/00:02:59, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:01:05/00:01:55, flags: T Incoming interface: Serial1, RPF nbr 10.1.9.2 Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:05/00:02:55

State in rtr-a before Pruning


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

105 105

State in rtr-b before Pruning SPT Case


Pay particular attention to the following: Both a (*, G) and (S, G) entries exist. The T flag is set in the (S, G) entry. This indicates that (S, G) traffic is being successfully received via the Shortest-Path Tree (SPT). The Incoming interface is different for the (*, G) and the (S, G) entry. This indicates that Shared Tree and the Shortest-Path tree diverge at this point.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

105

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1 3 (*,G) Prune

10.1.2.2

E0

1 IGMP Leave
Rcvr A

E1 2

rtr-b

1 2 3

rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

106 106

PIM SM Pruning Example SPT Case


1) The last-hop or Leaf router (rtr-b) receives an IGMP Group Leave message from Rcvr A for group G. After performing the normal IGMP Leave processing and finding that Rcvr A was the last host to leave, the IGMP state for group G on interface E1 is deleted. 2) This causes interface E1 to be removed from the Outgoing interface list of the (*, G) entry and any (Si, G) entries in the Multicast Routing Table. Because E1 was the only interface in the (*, G) and the (Si, G) entries, their outgoing interface lists become Null. 3) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is sent up the Shared Tree (RPT) via E0 toward the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

106

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1

Periodic (S, G) Join

rtr-b

Rcvr A

1 2 3 4

rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP. rtr-b stops sending periodic (S, G) joins.
1998 2001, Cisco Systems, Inc. All rights reserved.

Module5. ppt

8/10/2001 2:37 PM

107 107

PIM SM Pruning Example SPT Case (cont.)


4) Because the (Si, G) Outgoing interface list is now Null, rtr-b stops sending Periodic (Si, G) Join messages up the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

107

PIM SM Pruning
Source (SPT) Case
S1
(*,G) Prune (Si, G) Traffic Flow Shared Tree SPT Tree

To Source Si

To RP (10.1.5.1) 6
10.1.4.2

S0

rtr-a

10.1.2.2

E0

E0 10.1.2.1 5

E1

rtr-b

5 6

rtr-a receives Prune; removes E0 from (*,G) oilist.


(After the 3 second Multiaccess Network Prune delay.)

rtr-a (*,G) oilist now empty; sends (*,G) Prune toward RP.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

108 108

PIM SM Pruning Example SPT Case (cont.)


5) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si, G) state eventually times out. This causes a (Si, G) Prune to be sent up the Shortest-Path Tree (SPT) towards the source Si. 8) Traffic stops flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

108

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1

rtr-b

(*, 224.1.1.1), 00:02:32/00:02:59, RP 10.1.5.1, flags: S P Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: (171.68.37.121/32, 224.1.1.1), 00:01:56/00:00:53, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.2.1 Outgoing interface list:

State in rtr-b after Pruning


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

109 109

PIM SM Pruning Example SPT Case (cont.)


5) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si, G) state eventually times out. This causes a (Si, G) Prune to be sent up the Shortest-Path Tree (SPT) towards the source Si. 8) Traffic stops flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

109

PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1

rtr-b
RP RP 10.1.5.1, 10.1.5.1, flags: flags: S SP P nbr nbr 10.1.4.1, 10.1.4.1,

(*, (*, 224.1.1.1), 224.1.1.1), 00:02:32/00:02:59, 00:02:32/00:02:59, Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF Outgoing interface Outgoing interface list: list:

(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:56/00:00:53, 00:01:56/00:00:53, flags: flags: P PT T Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 10.1.9.2 10.1.9.2 Outgoing Outgoing interface interface list: list:

State in rtr-a after Pruning


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

110 110

PIM SM Pruning Example SPT Case (cont.)


5) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si, G) state eventually times out. This causes a (Si, G) Prune to be sent up the Shortest-Path Tree (SPT) towards the source Si. 8) Traffic stops flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

110

PIM SM Pruning
Source (SPT) Case
(Si,G) Data

To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

S1 S0

7 To Source Si

rtr-a
E0 10.1.2.1

8 (Si,G) Prune

10.1.2.2

E0

E1

rtr-b

7 8

Another (Si,G) data packet arrives via Serial1. rtr-a responds by sending an (Si,G) Prune toward source.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

111 111

PIM SM Pruning Example SPT Case (cont.)


5) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si, G) state eventually times out. This causes a (Si, G) Prune to be sent up the Shortest-Path Tree (SPT) towards the source Si. 8) Traffic stops flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

111

PIM SM Pruning
Source (SPT) Case
9 To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2

S1 S0

To Source Si

rtr-a
E0 10.1.2.1

10.1.2.2

E0

E1

rtr-b

7 8 9

Another (Si,G) data packet arrives via Serial1. rtr-a responds by sending an (Si,G) Prune toward source. (Si,G) traffic ceases flowing down SPT.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

112 112

PIM SM Pruning Example SPT Case (cont.)


5) The (*, G) Prune is received by rtr-a which causes interface E0 to be removed from the Outgoing interface list of the (*, G) entry in the Multicast Routing Table. (Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is a Multi-Access network and it needed to wait for a possible overriding Join from another PIM neighbor. Since none was received, the interface was pruned.) 6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is forwarded on up the Shared Tree (RPT) via S0 toward the RP. 7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si, G) state eventually times out. This causes a (Si, G) Prune to be sent up the Shortest-Path Tree (SPT) towards the source Si. 8) Traffic stops flowing down the Shortest-Path Tree (SPT).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

112

PIM-SM Protocol Mechanics

PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

113 113

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

113

PIM SM State Maintenance

Periodic Join/Prunes are sent to all PIM neighbors. Periodic Joins refresh interfaces in a PIM neighbors oilists. Periodic Prunes refresh prune state in a PIM neighbor. Received Multicast packets reset (S,G) entry expiration timers.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

114 114

PIM SM State Maintenance


In PIM SM, Join/Prune state information has an normal expiration time of 3 minutes. If a periodic Join/Prune message is not received to refresh this state information, it automatically expires and is deleted. Therefore, a PIM router sends periodic Join/Prune messages to its PIM neighbors to maintain this state information. When a Join message is received from a PIM Neighbor, the expiration timer of the interface (in the Outgoing interface list) from which the Join was received is reset to 3 minutes. If the interface expiration timer goes to zero, the interface is removed from the Outgoing interface list. (Note: This can trigger a Prune if the removal of the interface causes the Outgoing interface list to become Null.) When a Prune message is received in PIM Sparse mode, the interface on which the Prune was received is normally just removed from the Outgoing interface list. The exception to this is the special case of (S, G)RP -bit Prunes which are used to Prune (S, G) traffic from the Shared Tree. In this case, periodic (S, G)RP -bit Prunes must be sent in order to refresh the prune state in the upstream PIM Neighbor toward the RP. All (S, G) entries have entry expiration timers which are reset to 3 minutes by the receipt of an (S, G) packet received via the Shortest-Path Tree (SPT). If the source stops sending, this expiration timer goes to zero and the (S, G) entry is deleted.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

114

PIM Sparse Mode Review


Link Data Control

RP

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

115 115

PIM Sparse Mode Review


The following slides will review all the major concepts previously present in a sample network situation.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

115

PIM Sparse Mode Review


Receiver 1 Joins Group G C Creates (*, G) State, Sends (*, G) Join to the RP

RP Join

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

116 116

PIM Sparse Mode Review (cont.)


Receiver 1 joins group G by sending an IGMP Host message to C. C creates a (*, G) entry that has the interface towards Receiver 1 in the Outgoing interface list. C then sends a (*, G) Join up the Shared Tree toward the Rendezvous Point (RP).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

116

PIM Sparse Mode Review


RP Creates (*, G) State

RP

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

117 117

PIM Sparse Mode Review (cont.)


The Rendezvous Point (RP) receives the (*, G) Join from C and creates a (*, G) entry that has the interface towards C in the Outgoing interface list. The Shared Tree for group G has now been built (indicated by the arrows in the drawing) down to Receiver 1.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

117

PIM Sparse Mode Review


Source 1 Source 1 Sends Data A Sends Registers to the RP

Register

RP

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

118 118

PIM Sparse Mode Review (cont.)


Source 1 begins sending data to group G. (Note: It is not necessary for Source 1 to join group G by sending an IGMP Host Membership message before sending to group G.) A encapsulates Source 1 multicast packets in PIM Register messages and unicasts them to the Rendezvous Point (RP).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

118

PIM Sparse Mode Review


Source 1 RP De -Encapsulates Registers Forwards Data Down the Shared Tree Sends Joins Towards the Source

Join

Join

RP

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

119 119

PIM Sparse Mode Review (cont.)


The Rendezvous Point (RP) receives and de-encapsulates the Register messages and finds that it contains a packet for group G for which it has (*, G) state. The RP forwards the de-encapsulated packet down the Shared Tree. The RP then sends a Join towards Source 1 so that it can begin receiving native (I.e. unencapsulated) packets from the Source 1.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

119

PIM Sparse Mode Review


Source 1 RP Sends Register-Stop Once Data Arrives Natively

Register-Stop

RP

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

120 120

PIM Sparse Mode Review (cont.)


Once the data from Source 1 begins arriving natively, the Rendezvous Point (RP) sends a Register-Stop message to notify A that it no longer needs to encapsulate traffic in Register messages.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

120

PIM Sparse Mode Review


Source 1 C Sends (S, G) Joins to Join the Shortest Path (SPT) Tree

A (S, G) Join C

RP

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

121 121

PIM Sparse Mode Review (cont.)


Traffic exceeds the SPT-Threshold and C begins the process of switching to the Shortest-Path Tree (SPT) for Source 1 by sending an (S, G) Join to A up the SPT towards Source 1.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

121

PIM Sparse Mode Review


Source 1 C Sends Prunes Up the RP tree for the Source. RP Deletes (S, G) OIF and Sends Prune Towards the Source

(S, G) Prune

RP

(S, G) RP Bit Prune C E

Receiver 1

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

122 122

PIM Sparse Mode Review (cont.)


In order to prune Source 1 traffic from the Shared Tree (its now receiving this traffic via the Shortest-Path Tree), C sends an (S, G)RP -bit Prune up the Shared Tree. (Note: The RP-bit indicates to up-stream routers that this prune should flow up the Shared Tree (RPT) to the RP.) The RP receives the (S, G)RP-bit Prune and removes the interface (towards C) from the (S, G) oilist. This stops the flow of Source 1 traffic down the Shared Tree to C. The RPs (S, G) oilist is now Null (I.e. there are no other branches on the Shared Tree that want Source 1 traffic)and therefore no long needs Source 1 traffic. The RP responds by sending (S, G) Prunes towards Source 1. This stops the flow of Source 1 traffic to the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

122

PIM Sparse Mode Review


Source 1 New Receiver 2 Joins E Creates State and Sends (*, G) Join

B (*, G) Join C

RP

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

123 123

PIM Sparse Mode Review (cont.)


Receiver 2 also joins group G by sending an IGMP Host message to E. E creates a (*, G) entry that has the interface towards Receiver 2 in the Outgoing interface list. E then sends a (*, G) Join up the Shared Tree toward the Rendezvous Point (RP).

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

123

PIM Sparse Mode Review


Source 1 C Adds Link Towards E to the OIF List of Both (*, G) and (S, G) Data from Source Arrives at E

RP

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

124 124

PIM Sparse Mode Review (cont.)


C receives the (*, G) Join from E and adds the interface (towards E) to the oilist in both the existing (*, G) and (S, G) entries in the Multicast Routing table. (Note: Since C already had (*, G) state, it is not necessary to send a (*, G) join toward the RP again.) Group G traffic now begins flowing through C and E to Receiver 2.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

124

PIM Sparse Mode Review


Source 1 Source 2 Starts Sending, D Sends Registers, RP Forwards Data to Receivers down Shared Tree Register Source 2

RP

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

125 125

PIM Sparse Mode Review (cont.)


Source 2 now begins sending data to group G. (Note: Again, it is not necessary for Source 2 to join group G by sending an IGMP Host Membership message before sending to group G.) D encapsulates Source 2 multicast packets in PIM Register messages and unicasts them to the Rendezvous Point (RP). The Rendezvous Point (RP) receives and de-encapsulates the Register messages and finds that it contains a packet for group G for which it has (*, G) state. The RP forwards the de-encapsulated packet down the Shared Tree.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

125

PIM Sparse Mode Review


Source 1 RP Sends Joins to D

Register Join Source 2

RP

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

126 126

PIM Sparse Mode Review (cont.)


The RP then sends a Join towards Source 2 so that it can begin receiving native (I.e. unencapsulated) packets from the Source 2.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

126

PIM Sparse Mode Review


Source 1 Data begins flowing to RP down SPT, RP sends Register-Stop Register-Stop

RP

Source 2

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

127 127

PIM Sparse Mode Review (cont.)


Data from Source 2 begins arriving natively down the Shortest-Path Tree (SPT) via D. The Rendezvous Point (RP) sends a Register-Stop message to notify D that it no longer needs to encapsulate traffic in Register messages.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

127

PIM Sparse Mode Review


Source 1 Both Shared Tree and SPT in use

RP

Source 2

Receiver 1

Receiver 2

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

128 128

PIM Sparse Mode Review (cont.)


At this point, both the Shared Tree (Source 2 traffic) and a Shortest-Path Tree (Source 1 traffic) are being used to deliver group G traffic to the Receivers.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

128

PIM-SM Configuration Steps


Enable Multicast Routing on every router Configure every interface for PIM Configure the RP
Using Auto-RP or BSR
Configure certain routers as Candidate RP(s) Configure certain routers as Mapping Agents/CBSRs All other routers automatically learn elected RP

Anycast/Static RP addressing
RP address must be configured on every router Note: Anycast RP requires MSDP
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

129 129

Enable Multicast Routing (Forwarding) on every router.


This insures that there will be no multicast black-holes caused by a non multicast router in the unicast RPF path back to the source or RP.

Configure every interface for PIM


This insures that there will be no multicast black-holes caused by a non multicast interface in the unicast RPF path back to the source or the RP.

Configure the RP
Auto-RP (or BSR) are the simplest forms of RP configuration as they allow the routers in the network to automatically learn the address of the RP. This requires two additional command lines on one or more routers in the network that have been selected as candidate RPs. Configure one or more routers as Candidate RPs using the appropriate Auto-RP or BSR command. Configure one or more routers as Mapping Agents (Auto-RP) or Candidate BSRs (BSR). Anycast/Static RP addressing takes more work as the single RP address must be configured on every router in the network. Anycast RP is a form of redundant static RPs which requires the use of the Multicast Source Discovery Protocol (MSDP) but provides rapid RP failover.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

129

Enabling Multicast on the Router

Global Configuration Command


ip multicast-routing Enables IP multicast forwarding in the router. Configure on EVERY router in the network.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

130 130

Enabling Multicast on the Router


ip multicast-routing This command enables IP multicast forwarding on the router. Be sure to configure this command on every router in the network to avoid blackholes caused by a non multicast appearing in the unicast RPF path to a source or the RP.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

130

Enabling Multicast on an Interface


Interface Configuration Commands
Enables multicast forwarding on the interface. Controls the interfaces mode of operation.
ip pim dense-mode Interface mode is hard-wired to Dense mode operation. ip pim sparse-mode Interface mode is hard-wired to Sparse mode operation. ip pim sparse-dense-mode Interface mode is determined by the Group mode.
If Group is Dense, interface operates in Dense mode. If Group is Sparse, interface operates in Sparse mode. Decision is made on a packet-by-packet basis.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

131 131

Enabling Multicast on an Interface


The following commands enable multicast forwarding on an interface as well as determining the mode in which it operates. ip pim dense-mode Causes the interface to be hard-wired into operating in dense mode for all multicast traffic flows. ip pim sparse-mode Causes the interface to be hard-wired into operating in sparse mode for all multicast traffic flows. ip pim sparse-dense-mode Causes the interface to dynamically determine the interface mode on a packet-by-packet basis depending on whether the destination group is Dense mode, or Sparse mode. (This mode is shown by the D or S flag on the (*,G) entry.) If the destination group of a packet is in Dense mode, the interface uses dense mode operation to forward the packet. If the destination group of a packet is in Sparse mode, the interface uses sparse mode operation to forward the packet.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

131

Group Mode vs. Interface Mode


Avoid Group/Interface mode mismatches.
Group and Interface mode should be the same.
Otherwise you may get unwanted/unpredictable results.

Sparse-Dense interfaces always match the Group mode.


Should normally be used if running Auto-RP.
Permits Auto-RP groups to automatically run in Dense mode.
All other groups run in Sparse mode. (Assuming an RP is defined for all other groups.)

Can also be used for Sparse-only or Denseonly networks.


Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

132 132

Group Mode vs. Interface mode


Care should be taken to make sure that the Group mode always matches the interface mode. Otherwise, the forwarding mechanisms may not perform as desired/predicted. Group/Interface mismatches can be avoided by configuring ip pim sparse-dense-mode on an interface. This results in the interface always matching the Group mode. Sparse/Dense mode should normally be used if running Auto-RP. This allows the two Auto-RP groups (224.0.1.39 and 224.0.1.40) to operate in Dense mode. Once the routers in the network learn (via Auto-RP) the address of the elected RP, they will operate all other groups in Sparse mode. (By default, Auto-RP learned Group-to-RP ranges never include the Auto-RP groups.) Sparse/Dense mode can be also be used if pure Sparse mode or pure Dense mode operation is desired by either configuring or not configuring an RP address on each router, respectively.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

132

Group Mode vs. Interface Mode Common Misconception


Interface Mode controls Group Mode.
If I set all interfaces to ip pim sparse-mode, the router will always operate in Sparse mode and never fall back into Dense mode. Bzzzztt!!! Im sorry, but thats the incorrect answer. Group mode is independent of interface mode.
Interface mode only controls how the interface operates. Group mode is controlled by RP information!!!

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

133 133

Common Misconception
Interface Mode controls Group Mode. This is a classic error often made by network administrators. They assume that, If I set all interfaces to ip pim sparse-mode, the router will always operate in Sparse mode and never fall back into Dense mode. Unfortunately, this is incorrect. Group mode is solely controlled by the existence of a valid RP. If a valid RP is learned/configured for a group range, those groups will operate in sparse mode and the (*,G) entry will be created with the S flag set. Otherwise, the groups will operate in Dense mode and the D flag will be set on the (*,G) entry.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

133

Interface Mode Summary

Let Group mode control Interface mode.


Use ip pim sparse-dense-mode command.
Allows maximum flexibility. No need to ever change interface configuration.

Control Group mode with RP info.


If RP info exists, Group = Sparse.
Therefore interface mode = Sparse for this group.

If RP info does not exist, Group = Dense.


Therefore interface mode = Dense for this group.

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

134 134

Interface Mode Summary


By configuring all interfaces with ip pim sparse-dense-mode we allow the Group mode to determine the interface mode on a packet-by-packet basis. This allows maximum flexibility since we never have to reconfigure the interface to change mode. Control the Group mode (and hence the interface mode if ip pim sparse-densemode is configured) by defining RP information in the network. If a router has a valid RP address for a particular group, the group will be created in sparse mode; thereby causing the interface to operate in sparse mode when ip pim sparse-dense-mode is configured. If a router does not have a valid RP address for a particular group, the group will be created in dense mode; thereby causing the interface to operate in dense mode when ip pim sparse-dense-mode is configured.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

134

Avoiding DM Fallback

To always guarantee Sparse mode operation (and avoid falling back to Dense mode), make sure that every router always knows of an RP for every group.

Module5.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

135 135

How to avoid falling back into Dense mode.


It is often desired that the network NEVER fall back into Dense mode. Even if all primary and backup RPs fail, it is often better to have multicast forwarding stop instead of reverting back to dense mode. In order to prevent falling back into Dense mode, make sure that there is always an RP learned/configured for the entire multicast group range.

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

135

Avoiding DM Fallback
Define an "RP-of-last-resort.
Configure as a Static RP on every router.
Will only be used if all Candidate-RPs fall. Can be a dummy address.
Recommendation: Use lowest priority C-RP address.

Use ACL to avoid breaking Auto-RP


ip pim rp-address <RP-of-last-resort> 10 access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

136 136

Avoiding DM Fallback
In order to guarantee that the router will never fall back into dense mode, it is necessary to guarantee that the router will never loose RP information. This can be accomplished by defining a static, RP-of-last-resort in each router in the network. Since automatically learned RPs (Auto-RP or BSR) take precedence over statically defined RPs, the static entry will only be activated if all learned RPs timeout and/or fail. The recommendation is to define the lowest priority Candidate RP as the RP-of-last-resort by using a static RP definition pointing to this IP address. This locks the lowest priority RP into the bottom of the failover order. Even if this router fails (or its information times out), the static entry in each router will prevent a total loss of RP information. Special care must be taken if an RP -of-last-resort is defined when using Auto-RP. By default, a static RP definition that covers the Auto-RP group range will be interpreted as the RP for the two Auto-RP groups. (Unlike Auto-RP learned group ranges which have an implied deny for these two groups so that the two Auto-RP groups will default to using dense mode.) The following example shows how to configure an RP -of-last-resort so that the two Auto-RP groups do not accidentally switch to sparse mode: ip pim rp-address <RP-of-last-resort> 10 access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

136

Simple PIM-SM Configuration


RP/Mapping Agent A B

PIM Sparse Mode


C RP/Mapping Agent D

On every router: On every interface:

ip multicast-routing ip pim sparse-dense-mode

On routers B and C: ip pim send-rp-announce loopback0 scope 16 ip pim send-rp-discovery loopback0 scope 16

Module5. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/10/2001 2:37 PM

137 137

Example PIM-SM Configuration


The above example network shows how to configure a network to run Sparse mode using Auto-RP using two Candidate-RPs/Mapping Agents. Note: A common practice is to combine the function of Candidate-RP and Mapping Agent on the same router. This is done more as a configuration convenience than for any operational requirement. One every router in the network: Configure the ip multicast-routing global command to enable multicast on the router. Configure the ip pim sparse-dense-mode interface command on EVERY interface on each router. This allows the Auto-RP groups to function in Dense mode and all other groups to operate in Sparse or Dense mode depending on whether an RP has been configured for the group. On the router(s) that are to function as Candidate-RPs, configure the ip pim send-rp-announce Loopback0 scope <ttl> command. (Make sure the <ttl> value is sufficient to allow the message to reach all Mapping Agents in the network.) On the router(s) that are to function as Mapping Agents, configure the ip pim send-rp-discovery Loopback0 scope <ttl> command. (Make sure the <ttl> value is sufficient to allow the message to reach all routers in the network.) No additional configuration is generally necessary. The network is now completely enabled for PIM-SM IP Multicast!

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

137

Module5.ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

138

Copyright ? ?1999-2001, Cisco Systems, Inc.

Module5.ppt

138

Rendezvous Points
Module 6

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/13/2001 11:12 AM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Module Objectives

Explain the basic operation of Auto-RP. Explain the basic operation of PIMv2 BSR. Explain how to configure RPs How to use various IOS commands to tune and control RP operation.

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Module Agenda

Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RP Overview
All routers automatically learn RP address
No configuration necessary except on:
Candidate RPs Mapping Agents

Makes use of Multicast to distribute info


Two specially IANA assigned Groups used
Cisco-Announce - 224.0.1.39 Cisco-Discovery - 224.0.1.40

Typically Dense mode is used forward these groups

Permits backup RPs to be configured Can be used with Admin-Scoping


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Overview
Auto-RP allows all routers in the network to automatically learn Group-to-RP mappings. There are no special configuration steps that must be taken except on the router(s) that are to function as: Candidate RPs Mapping Agents Multicast is used to distribute Group-to-RP mapping information via two special, IANA assigned multicast groups. Cisco-Announce Group - 224.0.1.39 Cisco-Discovery Group - 224.0.1.40 Because multicast is used to distribute this information, a Chicken and Egg situation can occur if the above groups operate in Sparse mode. (Routers would have to know a priori what the address of the RP is before they can learn the address of the RP(s) via Auto-RP messages.) Therefore, it is recommend that these groups always run in Dense mode so that this information is flooded throughout the network. Multiple Candidate RPs may be defined so that in the case of an RP failure, the other Candidate RP can assume the responsibility of RP. Auto-RP can be configured to support Administratively Scoped zones. (BSR cannot!) This can be important when trying to prevent high-rate group traffic from leaving a campus and consuming too much bandwidth on WAN links.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RP Fundamentals
Candidate RPs
Multicast RP-Announcement messages
Sent to Cisco-Announce (224.0.1.39) group Sent every rp-announce-interval (default: 60 sec)

RP-Announcements contain:
Group Range (default = 224.0.0.0/4) Candidates RP address Holdtime = 3 x <rp-announce-interval>

Configured via global config command


ip pim send-rp-announce <intfc> scope <ttl> [group-list acl]

Deny in group-list has variable meaning


Before 12.0(1.1) Deny = Im not C-RP for this group-range After 12.0(1.1) Deny = Force group-range to always be DM
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Candidate RPs (C-RPs)


Multicast RP-Announcement messages to the Cisco-Announce (224.0.1.39) group. These messages announce this router as being a Candidate for selection as RP and are sent every 60 seconds by default. RP-Announce messages contain: Group Range (default is all multicast groups or 224.0.0.0/4) The Candidates IP address A holdtime which is used to detect when the C-RP has failed. This holdtime is 3 times the announcement interval or 3x60 = 180 seconds = 3 minutes C-RPs are configured using the (rather obtuse) command: ip pim send-rp-announce <intfc> scope <ttl> [group-list <acl>] The <intfc> specifies which IP address is used as the source address in the RP-Announce messages that are sent out all multicast interfaces on the router. The <ttl> value controls the TTL of the RP -Announce message. The optional group-list permits a group range other than the default to be assigned. This command may be configured more than once on a router so that the router will function as C-RP for multiple group ranges. Note: A deny in the group-list access-list has a different meaning beginning with IOS release 12.0(1.1). Before 12.0.(1.1): Deny means Im not the RP for this group range. After 12.0.(1.1): Deny means Force this group range to always work in Dense mode. Note: Only a single C-RP needs to deny this group range to force this to happen. In other words, the deny overrides any other routers permit advertisement.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RP Fundamentals
Mapping agents
Receive RP-Announcements
Stored in Group-to-RP Mapping Cache with holdtimes Elects highest C-RP IP address as RP for group range

Multicast RP-Discovery messages


Sent to Cisco-Discovery (224.0.1.40) group Sent every 60 seconds or when changes detected

RP-Discovery messages contain:


Elected RPs from MAs Group-to-RP Mapping Cache

Configured via global config command


ip pim send-rp-discovery [<interface>] scope <ttl>

Source address of packets set by <interface> (12.0)


If not specified, source address = output interface address Results in the appearance of multiple MAs. (one/interface)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Mapping Agents (MAs)


Mapping Agents join the RP -Announce group (224.0.1.39) in order to receive RP Announcements sent by all Candidate RPs. When they receive an Announcement they: Save the Announcement in the Group-to-RP mapping cache Select the C-RP with the highest IP address as RP for the group range The holdtimes are used to timeout an entry in the cache if a C-RP fails and is no longer sending periodic C-RP announcements. Mapping Agents periodically send the elected RPs from their Group-to-RP mapping cache to all routers in the network via RP Discovery messages. RP Discovery messages are multicast to the Auto-RP Discovery group 224.0.1.40. They are sent every 60 seconds or when a change to the information in the Group-to-Mapping takes place. MAs are configured using the (rather obtuse) command: ip pim send-rp-discovery[ <intfc>] scope <ttl> The optional <intfc> specifies which IP address is used as the source address in the RP-Discovery messages that are sent out all multicast interfaces on the router. (A Loopback interface is normally specified here.) If this interface is not specified, the source address of each multicast interface on the router is used. Note: The reason that this is an optional clause is strictly to be backwards compatible with IOS releases prior to 12.0 that did not allow the interface to be specified. In practice, an interface should always be specified. The <ttl> value controls the TTL of the RP -Discovery message.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RP Fundamentals

All Cisco routers


Join Cisco-Discovery (224.0.1.40) group
Automatic No configuration necessary

Receive RP-Discovery messages


Stored in local Group-to-RP Mapping Cache Information used to determine RP for group range

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

All Cisco Routers


Automatically join the Cisco-Discovery (224.0.1.40) group in order to receive Group-to-RP mapping information being multicast by the Mapping Agents in the network. No configuration is necessary! Group-to-RP mapping information contained in the RP -Discovery messages is stored in the routers local Group-to-RP mapping cache. This information is used by the router to map a Group address to the IP address of the active RP for the group.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Simple Auto-RP Configuration


RP/Mapping Agent A B

PIM Sparse Mode


C RP/Mapping Agent D

On each router: On each interface:

ip multicast-routing ip pim sparse-dense-mode

On routers B and C: ip pim send-rp-announce loopback0 scope 16 ip pim send-rp-discovery loopback0 scope 16

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Example Auto-RP Configuration


The above example network shows how to configure a network to run Sparse mode using Auto-RP and two Candidate-RPs/Mapping Agents. Note: A common practice is to combine the function of Candidate-RP and Mapping Agent on the same router. This is done more as a configuration convenience than for any operational requirement. One every router in the network: Configure the ip multicast-routing global command to enable multicast on the router. Configure the ip pim sparse-dense-mode interface command on EVERY interface on each router. This allows the Auto-RP groups to function in Dense mode and all other groups to operate in Sparse or Dense mode depending on whether an RP has been configured for the group. On the router(s) that are to function as Candidate-RPs, configure the ip pim send-rp-announce Loopback0 scope <ttl> command. (Make sure the <ttl> value is sufficient to allow the message to reach all Mapping Agents in the network.) On the router(s) that are to function as Mapping Agents, configure the ip pim send-rp-discovery Loopback0 scope <ttl> command. (Make sure the <ttl> value is sufficient to allow the message to reach all routers in the network.) No additional configuration is generally necessary. The network is now completely enabled for IP Multicast!

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RPFrom 10,000 Feet

Announce

MA A A
Announce

MA B B
Announce

Announce

Announce

Announce

RP- Announcements multicast to the Cisco Announce (224.0.1.39) group


Announce

Announce

C-RP 1.1.1.1

C C

D D

Announce

C-RP 2.2.2.2

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP - The big picture


In this example, routers A and B have been configured as Mapping Agents while routers C & D have been configured as Candidate RPs. Step 1 The Candidate RPs begin multicasting their candidacy to be the RP via RP Announce messages which are sent via the Cisco-Announce group, 224.0.1.39.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

Auto-RPFrom 10,000 Feet

Dis cov ery

MA A A
Dis cov ery

Disc ove ry

Dis cov ery


Disc ove ry

Disc ove ry

Dis cov ery

MA B B
Disc ove ry

C-RP 1.1.1.1

C C

D D

C-RP 2.2.2.2

RP-Discoveries multicast to the Cisco Discovery (224.0.1.40) group


Discovery

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

10 10

Auto-RP - The big picture


Step 2 The two Mapping Agents (routers A & B) receive the RP-Announce messages from the two Candidate RPs (routers C & D). Step 3 The C-RP with the highest IP address (in this case, router D) is stored in the Group-to-Mapping cache of the Mapping Agents. Step 4 The Mapping Agents both multicast the contents of their Group-to-RP Mapping Cache to the Cisco-Discovery group, 224.0.1.40. Note: All Mapping Agents are transmitting this Group-to-RP Mapping information simultaneously. The originally published specification on AutoRP implied that there was a Master-Slave relationship between Mapping Agents and that only the Master would transmit while the Slave(s ) were quiet until the Master failed. This specification is in error and this is not how Auto-RP has been implemented. As long as both Mapping Agents are transmitting identical information, there is no need to add the complexity of a Master-Slave failover scheme. Step 5 The RP Discovery messages are received via multicast by all routers in the network. The Group-to-RP mapping information contained in these messages is stored in the routers local Group-to-RP mapping cache. This information is subsequently used by the router to determine the IP address of the RP for a given group.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

10

Auto-RPA Closer Look


MA

C-RP 1.1.1.1

Rtr -A# show ip pim rp mapping This system is an RP -mapping agent

C-RP 2.2.2.2

C Initial Cache State in the Mapping Agent

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

11 11

Auto-RP Up Close
This is the same example that was presented in the previous slides. However, in this case, we will examine the process in more detail at each step. Step 1 At time zero, the Group-to-RP mapping caches in the Mapping Agents are empty since no RP-Announcements have been received. The output of the show ip pim rp mapping command shows that router A is a Mapping Agent and that the Group-to-RP mapping cache is empty.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

11

Auto-RPA Closer Look


MA

A
0/4 .0. 4.0 2 =2 .1 ge ec .1.1 Ran 80 s nce 1 - 1 ou = = RP roup ime Ann G oldt H

R G P= Ho roup 2.2.2 ldt im -R .2 e a An = 1 nge no 80 = 2 un sec 24 ce .0. 0.0 /4

C-RP 1.1.1.1

Rtr -A# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49

C-RP 2.2.2.2

C-RP Information is Stored in MAs Group-to-RP Mapping Cache Mapping Agent elects highest IP Address as RP
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

12 12

Auto-RP Up Close
Step 2 Routers C and D begin sending their RP Announce messages advertising themselves as a candidate to be RP for all multicast groups. (Note the group range, the IP address of the C-RP and the holdtime in the message.) Step 3 The Mapping Agent (router A) receives these RP Announcements and stores this information in its Group-to-RP mapping cache. The output of the show ip pim rp mapping command on the Mapping Agent (router A) now shows both router C and D as candidates for group range 224.0.0.0/4 (i.e. all multicast groups with the exception of the Auto-RP groups). The Mapping Agent then elects the C-RP with the highest IP address as the active RP for the group range.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

12

Auto-RPA Closer Look


MA

A
R G P= Ho roup 2.2.2 ldt . im - R 2 e an g = e= Di 180 224 sc se .0. ov c 0.0 ery /4

Mapping Agent advertises elected RP via Discovery messages

/4 .0.0 4.0 22 c e= se 2.2 ng 80 .2. Ra =1 ry =2 ve RP roup ime isco G oldt D H


13 13

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Auto-RP Up Close
Step 4 The Mapping Agent begins advertising the results of the RP election to the rest of the network via Auto-RP Discovery messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

13

Auto-RPA Closer Look

MA

All Mapping Agents Must Have Consistent Data !

MA

A
172.16.2.1

B
172.16.2.2

Rtr -A# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49

Rtr -B# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

14 14

Auto-RP Up Close
It is critical that all Mapping Agents in the PIM-SM domain have identical information in their Group-to-RP mapping caches. Note that in our example network, they do. If the information in the mapping caches are not identical, it can cause the routers in the network to flip-flop between two different RPs.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

14

Auto-RPA Closer Look


Local Cache Initially Loaded from Router B
MA
Rtr -X# show ip pim rp mapping Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr -D), v2v1 Info source: 172.16.2.2 ( Rtr -B), via Auto- RP Uptime: 00:00:03, expires: 00:02:57

MA

A
172.16.2.1

B
172.16.2.2

RP D G = 2 isc Ho roup .2.2 over ldt -R .2 y im a e = ng 18 e = 0 s 22 ec 4.0 .0.0 /4

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

15 15

Auto-RP Up Close
Step 6 Assume that router B is the first MA to send its RP Discovery message containing its Group-to-RP mapping cache contents. Step 7 The routers in the network (router X in this example) all receive this RP Discovery message and install the information in their local Group-to-RP mapping cache. The output of the show ip pim rp mapping command shows that router D is currently selected as the RP for group range 224.0.0.0/4 (i.e. all multicast groups with the exception of the Auto-RP groups) and that this information was most recently received from router B.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

15

Auto-RPA Closer Look


Identical Info Received from Router A
MA
Rtr -X# show ip pim rp mapping Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr -D), v2v1 Info source: 172.16.2.1 ( Rtr -A ), via Auto- RP Uptime: 00:00:03, expires: 00:02:57

MA

A
172.16.2.1

B
172.16.2.2

ry .0/4 ve co .0.0 24 Dis =2 2.2 e c .2. ang se = 2 - R 180 RP oup e = Gr ldtim Ho

Info source will continue to flip-flop between routers A and B No performance impact
X

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

16 16

Auto-RP Up Close
Step 8 Next, router A sends an RP Discovery message containing its Group-to-RP mapping cache contents. Step 9 The routers in the network (router X in this example) all receive this RP Discovery message and update the information in their local Group-to-RP mapping cache. Since both Mapping Agents are sending identical information, the only thing that will change in the local Group-to-RP mapping cache is the source of the information. The output of the show ip pim rp mapping command shows that router D is still selected as the RP for group range 224.0.0.0/4 (i.e. all multicast groups with the exception of the Auto-RP groups). However, the data reflects that this information was most recently received from router A. The flip-flop of the information source in the routers local Group-to-RP mapping cache has little or no performance impact on the router.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

16

Module Agenda

Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

17 17

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

17

PIMv2 BSR Overview


A single Bootstrap Router (BSR) is elected
Multiple Candidate BSRs (C-BSR) can be configured
Provides backup in case currently elected BSR fails

C-RPs send C-RP announcements to the BSR


C-RP announcements are sent via unicast BSR stores ALL C-RP announcements in the RP-set

BSR periodically sends BSR messages to all routers


BSR Messages contain entire RP-set and IP address of BSR Messages are flooded hop-by-hop throughout the network away from the BSR

All routers select the RP from the RP-set


All routers use the same selection algorithm; select same RP

BSR cannot be used with Admin-Scoping


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

18 18

BSR Overview
Bootstrap Router (BSR) A single router is elected as the BSR from a collection of Candidate BSRs. If the current BSR fails, a new election is triggered. The election mechanism is pre-emptive based on C-BSR priority. Candidate RPs (C-RPs) Send C-RP announcements directly to the BSR via unicast. (Note: C-RPs learn the IP address of the BSR via periodic BSR messages.) The BSR stores the complete collection of all received C-RP announcements in a database called the RP -set. The BSR periodically sends out BSR messages to all routers in the network to let them know the BSR is still alive. BSR messages are flooded hop-by-hop throughout the network. Multicast to the All-PIM Routers group (224.0.0.13 ) with a TTL of 1. BSR messages also contain: The complete RP-set consisting of all C-RP announcements. The IP Address of the BSR so that C-RPs know where to send their announcements. All routers receive the BSR messages being flooded throughout the network. Select the active RP for each group range using a common hash algorithm that is run against the RP-set. This results in all routers in the network selecting the same RP for a given group-range. BSR cannot be used with Admin-Scoping! Admin scoping was not considered when BSR was designed. One problem is that C-RP announcements that are unicast to the BSR cross multicast boundaries. There are several other problems as well.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 18

PIMv2 BSR Fundamentals


Candidate RPs
Unicast PIMv2 C-RP messages to BSR
Learns IP address of BSR from BSR messages Sent every rp-announce-interval (default: 60 sec)

C-RP messages contain:


Group Range (default = 224.0.0.0/4) Candidates RP address Holdtime = 3 x <rp-announce-interval>

Configured via global config command


ip pim rp-candidate <intfc> [group-list acl]

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

19 19

BSR Candidate RPs (C-RP)


C-RP Messages Sent periodically (default: 60sec) directly to the BSR via unicast. Messages contain the Group-range, C-RP address and a holdtime. The IP address of the current BSR is learned from the periodic BSR messages that are received by all routers in the network. C-RPs are configured using the following command: ip pim rp-candidate <intfc> [group-list <acl>] The <intfc> parameter dictates the IP Address that is advertised in the C-RP message. In most cases, a Loopback interface is used. The optional group-list access-list can be used to specify a group-range other than the default of 224.0.0.0/4 (i.e. all multicast groups) This command may be configured more than once on a router so that the router will function as C-RP for multiple group ranges.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

19

PIMv2 BSR Fundamentals


Bootstrap router (BSR)
Receive C-RP messages
Accepts and stores ALL C-RP messages Stored in Group-to-RP Mapping Cache w/holdtimes

Originates BSR messages


Multicast to All-PIM-Routers (224.0.0.13) group
(Sent with a TTL = 1)

Sent out all interfaces. Propagate hop-by-hop Sent every 60 seconds or when changes detected

BSR messages contain:


Contents of BSRs Group-to-RP Mapping Cache IP Address of active BSR
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

20 20

Bootstrap Router
The primary purpose of the Bootstrap router is to collect all C-RP announcements in to a database called the RP -set and to periodically send the RP-set out to all other routers in the network inside of BSR messages. BSR Messages Sent periodically (default: 60 secs) by the BSR out all multicast interfaces. BSR messages are multicast to the All-PIM-Routers (224.0.0.13) group with a TTL of 1. These messages are received by all PIM neighbors who retransmit them (again with a TTL of 1) out all interfaces except the one in which the messages was received. (An RPF check is done to insure the BSR message came in on the correct interface in the direction of the BSR.) BSR messages contain the RP-set and the IP address of the currently active BSR. (This is how C-RPs know where to unicast their C-RP messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

20

PIMv2 BSR Fundamentals


Candidate bootstrap router (C-BSR)
C-BSR with highest priority elected BSR
C-BSR IP address used as tie-breaker
(Highest IP address wins)

The active BSR may be preempted


New router w/higher BSR priority forces new election

Configured via global config command


ip pim bsr-candidate <intfc> <hash-length> [priority <pri>]

<intfc>
Determines IP address

<hash-length>
Sets RP selection hash mask length

<pri>
Sets the C-BSR priority (default = 0)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

21 21

Candidate Bootstrap Routers (C-BSRs)


C-BSRs participate in the BSR election mechanism. The C-BSR with the highest priority is elected as the BSR. The highest IP address of the C-BSRs is used as a tie-breaker. The election mechanism is preemptive. If a new C-BSR with a higher priority comes up, it triggers a new election. C-BSRs are configured using the following command: ip pim bsr-candidate <intfc> <hash-length> [priority <pri>] The <intfc> parameter is used to specify the BSRs IP address which is forwarded in BSR messages. (This is where C-RPs will send their messages if the C-BSR is elected as BSR.) The <hash-length> parameter specifies the number of bits in the hash. This can be used to control RP load balancing across a group range where different RPs are selected for different groups within a group range whose size is defined by the hash-length in bits. The optional <pri> value permits the C-BSR to be configured with a priority other than the default of zero.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

21

PIMv2 BSR Fundamentals


BSR election mechanism
C-BSRs:
Begin in Candidate-BSR state
BSR-Timeout timer started (150 seconds) If higher priority (preferred) BSR message received
Restart timer and forward BSR message Copy info to local Group-to-RP mapping cache Otherwise, discard BSR message

If timer expires, transition to Elected-BSR state

While in Elected-BSR state


Periodically originate own BSR messages
Include local Group-to-RP mapping cache in msg

Return to Candidate-BSR state if preferred BSR message (higher priority) received


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

22 22

BSR Election
How and when routers in the network forward BSR messages plays a key role in the BSR election mechanism. The algorithm used to decide whether to process and forward an incoming BSR message depends on whether the router is a Candidate BSR or not.

BSR Message forwarding by C-BSR routers


C-BSRs operate in one of two states, Candidate-BSR or Elected-BSR. Initially, a C-BSR comes up in C-BSR state.

C-BSR State
A BSR-Timeout timer started with a period of 150 seconds. If this timer expires, the router transitions to the Elected-BSR State. If a BSR message is received with higher priority than the C-BSRs priority, then the BSR (whose address is in the BSR message) is considered to be preferred and the BSR message is processed as follows: The BSR-Timeout timer is reset. The BSR message is forwarded out all other interfaces. The RP-set in the BSR message is copied into the local Group-to-RP mapping cache. If a BSR message is received with a priority less than the C-BSRs priority, the BSR message is simply discarded.

Elected BSR State


The router has been elected as the BSR and periodically originates BSR messages containing the current RP-set. If a BSR message is received from another router with a higher priority, forward the BSR message and transition back to C-BSR state; otherwise discard the BSR message.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 22

PIMv2 BSR Fundamentals

BSR election mechanism


Non C-BSRs (i.e., all other routers):
Start in Accept-Any state
Accepts first BSR message received Saves BSR info and forwards BSR message Transitions to Accept-Preferred state

While in Accept-Preferred state


Starts BSR-Timeout timer Only accept and forward preferred BSR messages
(i.e., BSR messages with priority > current BSR priority)

Otherwise, discard BSR message Return to Accept-Any state if timer expires

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

23 23

BSR Message forwarding by Non C-BSRs


Non C-BSR routers operate in two states, Accept-Any state and AcceptPreferred state. When a non C-BSR router boots up, it starts in the AcceptAny state.

Accept-Any State
Accept the first BSR message received and process it as follows: Copy the RP -Set into the local Group-to-RP mapping cache. Save the current BSR priority and BSR address in the BSR message. Transition to the Accept-Preferred state.

Accept-Preferred State
Start the BSR-Timeout timer with a period of 150 seconds. If this timer expires, transition back to the Accept-Any state. Accept only BSR messages that are preferred. (A preferred BSR message is one with a priority greater than or equal to the current BSR priority.) The accepted BSR message is then processed as follows: The BSR-Timeout timer is reset. The BSR message is forwarded out all other interfaces. The RP-set in the BSR message is copied into the local Group-to-RP mapping cache. Save the current BSR priority and BSR address in the BSR message. If a BSR message is received with a priority less than the C-BSRs priority, the BSR message is simply discarded. (Remember, the IP address of the BSR is used to break any ties with the winner being the C-BSR with the highest IP address.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

23

PIMv2 BSR Fundamentals

All PIMv2 routers


Receive BSR messages
Stored in local Group-to-RP Mapping Cache Information used to determine active BSR address

Selects RP using Hash algorithm


Selected from local Group-to-RP Mapping Cache All routers select same RP using same algorithm Permits RP-load balancing across group range

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

24 24

All PIMv2 Routers


Accept BSR messages based on the rules described in the previous pages. When a BSR message is accepted: The RP-Set in the BSR message is stored in the local Group-to-RP mapping cache. The BSR message is forwarded out all other interfaces (except the one in which it was received) on the router. Selects RP using a Hash Algorithm The RP for a group is selected from the set of C-RPs (stored in the Groupto-RP mapping cache) that have advertised their candidacy for a matching group-range. The same hashing algorithm is used by all routers to select the RP from the set of C-RPs in the RP-set. Since all routers run the same algorithm on the same RP-set (received from the BSR), all routers will select the same RP for a given group. The hashing algorithm permits multiple C-RPs to load balance the duties of RP across a range of groups. Only one C-RP will be selected as RP for any single group in the group range. However, the hash algorithm may select other C-RPs as RP for another group within the group range. For example, given a BSR hash length of 30 bits being used on IP v4 group addresses, this results in a remainder of 2 bits of an IPv4 address or 4 group addresses that a C-RP will serve as RP. In this scenario, if C-RP routers A and B both advertise their candidacy for group-range 224.1.1.0/24 and the hash algorithm selects router A as RP for 224.1.1.0, the hash length of 28 bits will also cause router A to be selected as RP for groups 224.1.1.1, 224.1.1.2 and 224.1.1.3 (i.e. a contiguous group range of of 4 addresses.) If the hash algorithm selects router B as RP for group 224.1.1.4, it will also select router B for groups 224.1.1.5, 224.1.1.6 and 224.1.1.7.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 24

Basic PIMv2 BSR


G
BSR Msgs

PIMv2 Sparse Mode


BSR Msgs

F
BSR Msgs
CRP Ad v (un ertise ica me st) nt

BSR
A
BSR Msgs

D
nt me ise ert t) v Ad as RP (unic C-

C-RP

B E

C-RP

BSR Msgs Flooded Hop -by-Hop

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

25 25

BSR Example
Step 1 Candidate RPs unicast their C-RP messages to the previously elected BSR. (The C-RPs learned the IP address of the BSR from the BSR messages that are being flooded throughout the network.) Step 2 The BSR receives and stores ALL C-RP information in a database called the RP-Set (which is stored in the Group-to-RP mapping cache on Cisco routers). Step 3 The BSR periodically sends BSR messages containing the RP -set out all of its interfaces. These BSR messages are forwarded hop-by -hop away from the BSR by all routers in the network. The RP -set is used by all routers in the network to calculate the RP for a group using a common hash algorithm.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

25

Module Agenda

Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

26 26

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

26

Static RPs
Hard-coded RP address
When used, must be configured on every router All routers must have the same RP address RP fail-over not possible
Exception: If Anycast RPs are used. (See MSDP module.)

Command
ip pim rp-address <address> [group-list <acl>] [override]

Optional group list specifies group range


Default: Range = 224.0.0.0/4 (Includes AutoAuto- RP Groups!!!!)

Override keyword overrides Auto-RP information


Default: Auto-RP learned info takes precedence

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

27 27

Hard-code RP Addresses
Requires every router in the network to be manually configured with the IP address of a single RP. If this RP fails, there is no way for routers to fail-over to a standby RP. The exception to this rule is if Anycast-RPs are in use. This requires MSDP to be running between each RP in the network.

Command
ip pim rp-address <address> [group-list <acl>] [override] The group-list allows a group range to be specified. The default is ALL multicast groups or 224.0.0.0/4 DANGER, WILL ROBINSON!!! The default range includes the Auto-RP groups (224.0.1.39 and 224.0.1.40) which will cause this router to attempt to operate these groups in Sparse mode. This is normally not desirable and can often lead to problems where some routers in the network are trying to run these groups in Dense mode (which is the normal method) while others are trying to use Sparse mode. This will result in some routers in the network being starved of Auto-RP information. This in turn, can result in members of some groups to not receive multicast traffic. The override keyword permits the statically defined RP address to take precedence over Auto-RP learned Group-to-RP mapping information. The default is that Auto-RP learned information has precedence.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

27

Module Agenda

Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

28 28

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

28

RP Placement

Q: Where do I put the RP?


A: Generally speaking, its not critical

SPTs are normally used by default


RP is a place for source and receivers to meet Traffic does not normally flow through the RP RP is therefore not a bottleneck

Exception: SPT-Threshold = Infinity


Traffic stays on the shared tree RP could become a bottleneck

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

29 29

PIM MFAQ (Most Frequently Asked Question)


Q: Where should I put the RP? A: Generally speaking, it is not critical. The default behavior of PIM-SM is to switch to the Shortest-Path Tree (aka the Source Tree) and bypass the RP as soon as a new source is detected. This means that in most cases, multicast traffic does not flow through the RP. Therefore, the RP does not become a point of congestion. The default behavior can be overridden in Cisco routers by setting the SPTThreshold to Infinity. This prevents the Cisco router from joining the SPT and keeps all group traffic flowing down the Shared Tree. In this case, the RP could become a bottleneck.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

29

RP Performance Considerations
CPU load factors
RP must process Registers RP must process Shared-tree Joins/Prunes RP must send periodic SPT Joins toward source PIM performs RPF recalculation every 5 seconds
Watch the total number of mroute table entries in the RP Only when spt-threshold = infinity is in use

Shared-tree forwarding

Memory load factors


(*, G) entry ~ 380 bytes + OIL size (S, G) entry ~ 220 bytes + OIL size Outgoing interface list (OIL) size
Each oil entry ~ 150 bytes
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

30 30

RP Performance Considerations
CPU Load Factors The RP will receive all Register messages for any new sources in the network. Although processing of Register messages is done at Process Level, the impact on the router is usually small since the RP will immediately send back a Register-Stop message. The RP will receive and must process all Shared Tree Join/Prune messages from downstream routers on the Shared Tree. Downstream routers continue to send periodic (once a minute) Join/Prune messages up the Shared Tree. The number of these Join/Prune messages is generally quite small and therefore has little impact on the RP. The RP must send periodic (once a minute) SPT Joins toward all sources for which it has members active on a branch of the Shared Tree. In order to detect a network topology change, ALL PIM routers perform an RPF recalculation on every (*, G) and (S, G) entry in the mroute table every 5 seconds. The impact of this will grow as the total number of entries in the mroute table increase and as the number of entries in the unicast routing table increase. (The later is due to the fact that each RPF calculation requires the route to the source to be looked up in the unicast routing table. If this table is quite large, as would be the case for poorly aggregated address space, the lookup can take more effort than when the number of entries is kept small.) Except for the following load factor, this is the most significant CPU load factor. Any traffic that does have to flow through the RP requires it to replicate the packets out all outgoing interfaces. Memory Factors The amount of memory consumed by PIM is primarily a function of the size of the mroute table. (See the numbers in the slide for details.)
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 30

Dealing with Overloaded RPs

Increase CPU horsepower Increase memory Use SPTs if not already Split RP load across several RPs!

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

31 31

Dealing with overloaded RPs


If possible, increase the CPU horsepower of the RP. In some cases, this can be accomplished by changing the RP or RSP card in the router. If the multicast traffic in the network results in an extremely large number of mroute table entries, it may be necessary to increase the amount of memory in the router. This scenario is not likely to occur except in the cases where a lowend router with a minimal amount of memory is used in a network with a large number of multicast sources. If the RP is overloaded due to the multicast packet replication and forwarding demands, insure that Shortest Path Trees are in use by making sure all routers in the network have an SPT-Threshold set to the default value of zero. If all else fails, split the RP load across several RPs by assigning different group ranges to different RPs. (The Anycast-RP technique can be used in conjunction with MSDP to allow more than on RP to be active for a single group and to share the load.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

31

Auto-RP Announcement Scope


RP Announcements Leaking Outside of Network

PIM Sparse Mode Network


scope 16 scope 16 C Candidate-RP A Mapping Agent B Mapping Agent

RP Announcements Not Reaching this Map Agent Network Diameter = 32 Hops


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

32 32

Auto-RP Announcement Scope


Care must be taken in the selection of the TTL scope of RP Announcement messages that are sent by C-RPs to insure that the messages reach all Mapping Agents in the network.

Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpannounce command on the C-RP router. However, the maximum diameter of the network is greater than 16 hops and in this case one Mapping Agent is further away than 16 hops. As a result, this Mapping Agent does not receive the RP Announcement messages from the C-RP. This can cause the two Mapping Agents to have different information in their Group-to-RP mapping caches. If this occurs, each Mapping Agent will advertise a different router as the RP for a group which will have disastrous results. Notice also, that the C-RP is fewer than 16 hops way from the edge of the network. This can result in RP Announcement messages leaking into adjacent networks and causing Auto-RP problems in those networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

32

Auto-RP Announcement Scope


RP Announcements (224.0.1.39) Blocked from Leaving/Entering the Network Using ip multicast boundary Commands

scope 32 C Candidate-RP

scope 32

PIM Sparse Mode Network


B Mapping Agent

A Mapping Agent

Both Mapping Agents Are Now Receiving Announcements from the Candidate RP Network Diameter = 32 Hops
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

33 33

Auto-RP Announcement Scope


The best way to avoid the problems on the preceding page is to use a sufficiently large enough scope so that the RP Announcement messages reach all Mapping Agents in the network.

Example
In the above diagram, the maximum network diameter is 32. Therefore by setting the scope to 32 or greater, we are assured that the RP Announcements will reach both Mapping Agents shown in the example network. In order to prevent RP Announcement messages from leaking into adjacent networks, a multicast boundary is defined for the Cisco-Announce (224.0.1.39) multicast group on all border routers in the network. This not only stops RP Announcement messages from leaking out, it more importantly, stops any from leaking in from adjacent networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

33

Auto-RP Discovery Scope


RP Discovery Messages Leaking Outside of Network RP Discovery Messages Not Reaching this Router (Assumes All Groups Are Dense Mode)
scope 16 scope 16 A Mapping Agent

PIM Sparse Mode Network

Network Diameter = 32 Hops


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

34 34

Auto-RP Discovery Scope


Care must be taken in the selection of the TTL scope of RP Discovery messages that are sent by Mapping Agents to insure that the messages reach all routers in the network.

Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpdiscovery command on the Mapping Agent. However, the maximum diameter of the network is greater than 16 hops and in this case, at least one router is further away than 16 hops. As a result, this router does not receive the RP Discovery messages from the MA. This can result in the router having no Group-to-RP mapping information. If this occurs, the router will attempt operate in Dense mode for all multicast groups while other routers in the network are working in Sparse mode. Notice also, that the MA is fewer than 16 hops way from the edge of the network. This can result in RP Discovery messages leaking into adjacent networks and causing Auto-RP problems in those networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

34

Auto-RP Discovery Scope


RP Discovery Messages Now Reaching this Router RP Discoveries (224.0.1.40) Blocked From Leaving/entering the Network Using ip multicast boundary Commands

scope 32 A Mapping Agent

scope 32

PIM Sparse Mode Network

Network Diameter = 32 Hops


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

35 35

Auto-RP Discovery Scope


The best way to avoid the problems on the preceding page is to use a sufficiently large enough scope so that the RP Discovery messages reach all routers in the network.

Example
In the above diagram, the maximum network diameter is 32. Therefore by setting the scope to 32 or greater, we are assured that the RP Discovery messages will reach the farthest router in the network. In order to prevent RP Discovery messages from leaking into adjacent networks, a multicast boundary is defined for the Cisco-Discovery (224.0.1.40) multicast group on all border routers in the network. This not only stops RP Discovery messages from leaking out, it more importantly, stops any from leaking in from adjacent networks.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

35

Constraining Auto-RP Messages


Need to Block Auto-RP Discovery (224.0.1.40) and Announcement (224.0.1.39) Messages from Entering/Leaving the Network

Boundary Router scope 32 scope 32 A Mapping Agent

S0

scope 32

scope 32

C Candidate-RP

Interface S0 ip multicast boundary 10

PIM Sparse Mode Network

access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

36 36

Constraining Auto-RP Messages


This example shows how to configure the multicast boundary on a border router so that Auto-RP messages do not leak into or out of the network. On the border interface (in this case, Serial0) the ip multicast boundary command is used. The access list associated with the ip multicast boundary command is as follows: access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any The above access list stops the flow of multicast traffic for the two Auto-RP groups (224.0.1.39 and 224.0.1.40) while allowing all other multicast traffic to enter or exit via interface Serial 0.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

36

Constraining BSR Messages


Need to Block All BSR Message from Entering/Leaving Network
Border Router
S0

PIMv2 Sparse Mode Network


BSR Msgs BSR BSR Msgs

Need to Block All BSR Message from Entering/Leaving Network


Border Router B
S0

Neighboring PIMv2 Domain

Neighboring PIMv2 Domain

Interface S0 . . ip pim bsr-border

Interface S0 . . ip pim bsr-border

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

37 37

Constraining BSR Messages


Like Auto-RP, allowing BSR messages to leak into or out of a network can cause problems both in the local network and in adjacent networks. In order to block BSR messages from entering or exiting on a given interface, the ip pim bsr-border interface command can be used.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

37

Controlling RP Acceptance
What really determines if a router is the RP
Any router will assume the duties of the RP if:
It receives a (*,G) Join that contains an RP address that is the IP address of one of its interfaces AND The interface is multicast enabled AND The RP address matches the RP in the Group-to-RP mapping cache OR There is no entry in the Group-to-RP mapping cache.

Misconfigured routers could create multiple RPs in the network


Each sends a (*,G) Join with a different RP address Each (*,G) Join results in another RP for the same group

The Accept-RP command provides additional control (insurance?) to prevent this.


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

38 38

By default, a router operates as an RP for a group if:


It receives a (*, G) Join containing one of its addresses as the RP or It receives a (S, G) Register message.

Basic sanity check


Routers will perform a rudimentary sanity check to see if it actually should be the RP for group G by searching the Group-to-RP mapping cache for an entry for group G. If an entry is found and the RP for the group is not this router, then the router will discard the (*, G) Join or (S,G) Register and will not become the RP. Otherwise, it will assume that it is the RP for group G and assume duties of the RP.

Extended sanity checking


In order to provide additional control and sanity checking over which router should be accepted as the RP, the IOS command ip pim accept-rp was created.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

38

Controlling RP Acceptance
Accept-RP Command
Global configuration commands
ip pim accept-rp <rp-address> [<acl>] ip pim accept-rp Auto-rp [<acl>] ip pim accept-rp 0.0.0.0 [<acl>]

Multiple commands accepted


Command list sorted in order shown above Only one Auto-RP and one 0.0.0.0 (wildcard) accepted Omitting ACL implies 224.0.0.0/4 group range

Search Rules
Top down search Stop on RP address matchApply ACL and exit Exception: Auto-RP denies RP/Group
Apply 0.0.0.0 (wildcard) entry (if it exists)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

39 39

Command format
ip pim accept-rp <rp-address> [<acl>] ip pim accept-rp Auto-rp [<acl>] ip pim accept-rp 0.0.0.0 [<acl>] The option <acl> is used to specify which groups are valid using standard permit and deny clauses. Omitting the <acl> assumes a permit 224.0.0.0 15.255.255.255. If more than one of the above commands is configured, they are sorted in the order shown above. The Auto-rp entry matches any RP address learned via Auto-RP. (Note: This form has implied deny clauses for the Auto-RP groups, 224.0.1.39 and 224.0.1.40, that cannot be overridden in the optional <acl>. This helps prevent the Auto-RP groups from accidentally switching to Sparse mode.) The 0.0.0.0 (wildcard) matches any RP address. While multiple ip pim accept-rp <rp-address> commands may be configured, only a single Auto-rp and a single 0.0.0.0 (wildcard) command is accepted.

Search Rules
The list of configured commands is searched from top down and stops at the first entry that matches the RP address. The <acl> is applies and the RP is either permitted or denied. Exception: If an Auto-RP entry denies an RP and a 0.0.0.0 entry exists, the 0.0.0.0 entry is also tried.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

39

Controlling RP Acceptance

Accept-RP Command Usage


Case 1 Controlling Group mode Case 2 Accepting (*, G) joins Case 3 Accepting PIM registers at the RP

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

40 40

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

40

Accept-RPCase 1

Controlling Group Mode


Router Has No State for Group G IGMP Join (G)

Search Groupto-RP Mapping Cache

Accept-RP Filter List

State Creation Engine

Group Group Address Address

Group Group Address, Address, RP RP Address Address

Permit Permit

Sparse Sparse Mode Mode

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

41 41

Case 1 - Controlling Group Mode


If a router has no (*, G) state when an IGMP Membership Report is received for group G, the router will apply the configured Accept-RP rules to determine if there is a valid RP for this group or not. If there isnt, the (*,G) entry is created and set as a Dense mode group. If there is a valid RP, the (*,G) entry is set in Sparse mode. Step 1 The Group-to-RP mapping cache is searched for the group address in the IGMP Join message. If an entry is not found, then the group is created in Dense mode. Step 2 If a matching entry is found in the Group-to-RP mapping cache, the Group and RP addresses are run through the Accept-RP filters. If a permit is returned, then the group is created in Sparse mode; otherwise the group is created in Dense mode.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

41

Accept-RPCase 2

Accepting (*, G) Joins


A A

(*, G) Join Messages Contain the RP Address (*, G) Join

B B

Accept-RP Filter List

Join Processing Engine

Group Group Address Address RP RP Address Address

RP RP Address Address

Process Process Join Join

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

42 42

Case 2 - Accepting (*, G) Joins


If a router receives (*, G) Join it will apply the configured Accept-RP rules to determine if the RP address contained in the (*, G) Join is valid or not. Step 1 (not shown) The Group-to-RP mapping cache is searched for the group address in the (*, G) Join message. If an entry is found and it is a negative entry indicating that the group has been forced to always be in Dense mode, then the (*, G) Join is not accepted and an error message is generated. Step 2 The Group and RP addresses (contained in the (*, G) Join) are run through the Accept-RP filters. If a permit is returned, then the (*, G) Join is processed normally; otherwise the (*, G) Join is dropped and an error message is generated.

Example
When Auto-RP is in use, it is normally the case that the two Auto-RP groups, 224.0.1.39 and 224.0.1.40 should be operating in Dense mode. However, if a downstream router is misconfigured with a static RP address, it will send (*, G) Joins for these Auto-RP groups. The routers that receive these (*, G) Joins will create a (*,G) entry in Sparse mode for these Auto-RP groups. This can result in portions of the network trying to operate these groups in Dense mode while other parts of the network are operating in Sparse mode. This will generally cause the Auto-RP mechanisms to fail. The following Accept-RP command will cause a router to reject any (*,G) Joins for the Auto-RP groups and prevent these Joins from propagating. ip pim accept-rp Auto-rp

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

42

Accept-RPCase 3

Accepting PIM Registers at the RP


(S, G) Register Unicast to One of As Interface Addresses RP

Source S

B B

A A

Accept-RP Filter List

RP Processing Engine

Group Group Address, Address, Interface Interface Address Address

Permit Permit

RP

Accept Accept the the Register Register

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

43 43

Case 3 - Accepting PIM Register messages


If a router receives PIM Register message, it will apply the configured AcceptRP rules to determine if the router is permitted to be the RP or not. Step 1 (not shown) The Group-to-RP mapping cache is searched for the group address in the (*, G) Join message. If an entry is found and it is a negative entry indicating that the group has been forced to always be in Dense mode, then the PIM Register is not accepted, a Register-Stop is sent back to the firsthop router and an error message is generated. Step 2 The Group (contained in the multicast packet encapsulated in the Register message) and RP addresses (the destination IP address in the Register message) are run through the Accept-RP filters. If a permit is returned, then the PIM Register is processed normally; otherwise a Register-Stop is sent back to the first-hop router and an error message is generated.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

43

Filtering C-RP Announcements


Use on Mapping Agents to filter out bogus C-RPs
Some protection from RP-Spoofing denial-of-service attacks Multiple commands may be configured as needed

Global command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>] rp-list <acl>
Specifies from which routers C-RP Announcements are accepted.

group-list <acl>
Specifies which groups in the C-RP Announcement are accepted. If not specified, defaults to deny all groups

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

44 44

Filtering RP Announcements
Network Administrators may wish to configure Mapping Agents so that they will only accept C-RP Announcements from well-known routers in the network. This will prevent C-RP Announcements from bogus routers from being accepted and potentially being selected as the RP.

Global Command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>] The rp-list <acl> specifies the IP address(es) from which C-RP announcements will be accepted. The option group-list <acl> specifies the group range(s) that are acceptable for the routers in the rp-list. If not specified, the default group-list <acl> is deny all Multiple instances of this command may be configured.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

44

Controlling Source Registration


New global command - IOS 12.0(6)
ip pim accept-register [list <acl>] | [route-map <map>]

Used on RP to filter incoming Register messages Filter on Source address alone (Simple ACL) Filter on (S, G) pair (Extended ACL) May use route-map to specify what to filter
Filter by AS-PATH if (m)BGP is in use.

Prevents unwanted sources from sending


First hop router blocks traffic from reaching net Note: Source can still send traffic on local wire
45 45

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Controlling Source Registration


In some cases, it may be desirable to control which hosts in the network can actually source traffic to a group. While there is currently no way to prevent a bogus source from transmitting traffic on its local segment, we can prevent it from being registered to the RP. This will, in most cases, prevent this traffic from going past the first-hop router and reaching other hosts in the network. A new IOS command, ip pim accept-register was introduced which when configured on an RP, controls which (S, G) Register messages will be accepted and which will be rejected.

Global Command (IOS 12.0(6) or later)


ip pim accept-register [list <acl>] | [route-map <map>] If the list <acl> is specified, the <acl> can either be a simple access list to control which hosts may send to any groups or an extended access list that specifies both source and group address combinations that are permitted or denied from sending. If the route-map <map> is specified, then only matching (S, G) traffic will be accepted. (Note: This permits other matching criteria to be considered such as AS-PATH.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

45

Module Agenda

Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

46 46

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

46

Debugging Auto-RP Operation


Understand the Auto-RP mechanisms
This is the fundamental debugging tool for problems with AutoAuto -RP!!!

Verify Group-to-RP Mapping Caches


First on the Mapping Agents
Other routers will learn Group-to-RP mapping info from these routers
If not correct, use debug commands to see whats wrong

Make sure all MAs have consistent Group-to-RP information


If not, watch for TTL Scoping problems

Then on other routers


If info doesnt match MA, there is a problem distributing the information Use show and debug commands to find where the break is
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

47 47

Debugging Auto-RP
First and foremost, you must understand the fundamental mechanisms behind Auto-RP in order to debug problems! Verify Group-to-RP Mapping Caches on Mapping Agents Because other routers in the network will learn the Group-to-RP mapping information from the Mapping Agents, it is important that this information is correct on the Mapping Agents. If the information is not correct, verify that the C-RPs are configured correctly and that C-RP Announcements are being received properly by the Mapping Agent. If multiple Mapping Agents are in use, make sure that their Group-to-RP mapping information is identical. If not, the routers in the network will oscillate between the different RPs selected by the Mapping Agents. Again, make sure all Mapping Agents are properly receiving Auto-RP Announcements from all C-RPs in the network. Watch out for TTL scoping problems! Verify Group-to-RP Mapping Caches on all other routers Group-to-RP mapping information should match the MAs. If not, verify that the router is properly receiving Auto-RP Discovery messages from the Mapping Agents. Again, watch out for TTL scoping problems!

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

47

Debugging Auto-RP Operation

Insure Auto-RP group state is correct


Should normally be in Dense mode Watch out for mixed DM and SM conditions
Can occur when Static RPs are also defined
Always deny Auto-RP groups on Static RP configurations

Use Accept-RP filters on all routers as insurance

Watch out for DM problems in NBMA networks


(See Module 7 for details)

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

48 48

Common Problem - Incorrect Auto-RP Group mode


The two Auto-RP groups, 224.0.1.39 and 224.0.1.40 are normally run in Dense mode so that this information is flooded throughout the network. Only in very rare situations is it desirable to run these two groups in Sparse mode because this creates a chicken-and-the-egg problem. (How do you join the RP for the Auto-RP groups if you dont know the RP address?) Therefore, the following situations should be verified: Insure that the Auto-RP groups are operating in Dense mode on all routers in the network. Mixed DM/SM situations can arise when static RP addresses have been configured on some routers in the network. To avoid this: Always specify an <acl> on any ip pim rp-address commands that denies groups 224.0.1.39 and 224.0.1.40. Configure Accept-RP filters on all routers in the network that deny groups 224.0.1.39 and 224.0.1.40. (Note: The ip pim accept-rp auto-rp command has an implied set of deny clauses for these two groups to prevent them from switching into Sparse mode.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

48

Debugging BSR Operation


Understand the BSR mechanisms
This is the fundamental debugging tool for problems with BSR!!!

Verify Group-to-RP Mapping Caches


First on the BSR
Other routers will learn Group-to-RP mapping info from this router
If not correct, use debug commands to see whats wrong

Then on other routers


If info doesnt match BSR, there is a problem distributing the information Use show and debug commands to find where the break is

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

49 49

Debugging BSR Operation


First and foremost, you must understand the fundamental mechanisms behind BSR in order to debug problems! Verify Group-to-RP Mapping Caches on the elected BSR. Because other routers in the network will learn the Group-to-RP mapping information from the elected BSR, it is important that this information is correct on this router. If the information is not correct, verify that the PIMv2 C-RPs are configured correctly and that C-RP Announcements are being received properly by the BSR. Verify Group-to-RP Mapping Caches on all other routers Group-to-RP mapping information should match the BSR. If not, verify that the router is properly receiving BSR messages.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

49

Module Agenda

Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

50 50

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

50

RP on a Stick
Triggering conditions on the RP:
A (*,G) entry (i.e. Shared Tree) exists with a single outgoing interface on the RP. And an (S,G) entry (i.e a Source) exists on the same interface with a Null outgoing interface list.

Results in special state at the RP


Frequently misunderstood and rarely seen
Default behavior is to join SPT which avoids this

Mishandled in versions of IOS prior to 12.0 Requires the Proxy Join Timer to resolve Need to understand concept of atomic joins
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

51 51

RP on a Stick
This is a special situation that occurs under the following conditions: All branches of the Shared Tree are out a single interface on the RP (i.e. there is only a single interface in the (*, G) OIL at the RP.) All sources for the group are out the same interface. (This would result in (S, G) entries with Null OILs since the incoming interface can never appear in the OIL of an entry.)

Unusually State results in this condition


Special PIM rules had to be created that were not in the original PIMv2 specification in order to avoid situations where : (S, G) traffic flows were incorrectly pruned. (S, G) traffic continued to flow to the RP only to be dropped. (S, G) state would get stuck in the RP and the First-Hop router even when the source has long since stopped sending. Problem was solved in IOS 12.0 by: Special Proxy Join Timer and Introduction of Atomic and Non-Atomic (*, G) Joins

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

51

RP on a Stick
RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

52 52

RP-on-a-Stick Example
Consider that above network topology where both rtr-b and rtr-c share a common Ethernet segment with the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

52

RP on a Stick
Shared Tree

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0
(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39

rtr-c
E0

Member 224.1.1.1

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

53 53

RP-on-a-Stick Example
When a host behind rtr-c joins group 224.1.1.1, a branch of the Shared Tree is created (shown by the solid arrow) which results in the following state on the RP: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

53

RP on a Stick
Shared Tree

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SC Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Member 224.1.1.1

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

54 54

RP-on-a-Stick Example
This also results in the following state on rtr-c: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SC Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

54

RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

Source 192.1.1.1

Member 224.1.1.1

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

55 55

RP-on-a-Stick Example
Now assume that source 192.1.1.1 behind rtr-b begins sending to group 224.1.1.1. After the normal Register process has completed, a branch of the SPT (shown by the heave dashed arrow) is built from rtr-b to the RP. This allows traffic to flow to the members as shown by the thin dashed arrows.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

55

RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SP Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: (192.1.1.1/32,Source 224.1.1.1), 00:00:49/00:02:46, flags: T Incoming interface: 192.1.1.1Ethernet0, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:49/00:02:11
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1

56 56

RP-on-a-Stick Example
The creation of the SPT results in the following state on rtr-b: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SP Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:49/00:02:11

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

56

RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), Source 00:00:49/00:02:46, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, 192.1.1.1 Outgoing interface list:

rtr-c
E0

Member 224.1.1.1

Normally results in the suppression of (S,G) Joins


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

57 57

RP-on-a-Stick Example
The creation of the SPT also results in the following state on the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Notice that the OIL of the (S, G) entry is Null which, in turn, results in the P flag being set. Normally, this would cause the RP to send an (S, G) Prune toward the source to shut off the flow of (S, G) traffic. However in this case, that would starve the host behind rtr-c of the desired group traffic. Obviously, something else must be done to prevent this.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

57

RP on a Stick

Solution requires three new concepts


Atomic & Non-Atomic Joins Proxy Join Timer/Flag Header-only Registers

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

58 58

RP-on-a-Stick Solution
In order to deal of this special situation, several new concepts were added to the 12.0 implementation of PIM. These are: Atomic vs. Non-Atomic (*, G) Joins The Proxy Join Timer (and its flag) on (S, G) entries Header-only Registers (aka Data-less Registers) Each of the above are discussed in the following pages

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

58

RP on a Stick

Non-Atomic Joins
Contains (*, G) Join for group G only
This is the type of (*, G) Join we are familiar with

Atomic Joins
Contains (*, G) Join for group G followed by (S, G)RP-bit Prunes for all sources in group G
Used to prune unnecessary (S, G) traffic from the Shared Tree after switchover to the SPT.

All in the same PIM Join/Prune message

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

59 59

Non-Atomic Joins
This is a PIM Join/Prune message that contains only a (*, G) Join for group G in the Join list without any associated (S, G)RP-bit Prunes for group G in the Prune list. This is the typical (*, G) Join that has been described in most of the examples in Module 5, PIM -SM.

Atomic Joins
This is a PIM Join/Prune message that contains a (*, G) Join for group G in the Join list AND a complete list of all (S, G)RP-bit Prunes for group G in the Prune list. Remember, these (S, G)RP -bit Prunes are used to Prune specific (S, G) traffic off of the Shared Tree after a router has joined the SPT directly toward the source.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

59

RP on a Stick
PIM Join/Prune Message
Header (10.1.4.1, 224.1.0.5) (10.1.4.1, 224.1.1.1) (10.1.4.1, 224.2.2.2) Join List (10.1.19.21, 224.2.2.2) . . . (10.1.19.21, 224.1.0.5) (10.1.4.1, 224.3.3.3) (192.1.1.1, 224.1.1.1) Prune List (192.1.4.2, 224.2.2.2) . . .
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

WC, RP WC, RP WC, RP RP (*, G) Join + (S, G)RP-bit Prune = Atomic Join

WC, RP RP

60 60

Example: Atomic (*, G) Join


In this example, a (*, G) entry for group 224.1.1.1 in the Join list of the PIM Join/Prune message. (The WC (wildcard) and RP (RP -Tree) bits tell us that this entry is a (*, G) Join to RP 10.1.4.1) In addition, there is an (S, G) entry for group 224.1.1.1 (192.1.1.1, 224.1.1.1) with the RP-bit set in the Prune list. (I.e. an (S, G)RP-bit Prune exists for group 224.1.1.1). Because both a (*, G) Join along with one or more (S, G)RP-bit Prunes exist in this Join/Prune message for group 224.1.1.1, it is said to contain an Atomic (*, G) Join for group 224.1.1.1.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

60

RP on a Stick
PIM Join/Prune Message
Header (10.1.4.1, 224.1.0.5) (10.1.4.1, 224.1.1.1) (10.1.4.1, 224.2.2.2) Join List (10.1.19.21, 224.2.2.2) . . . (10.1.19.21, 224.1.0.5) (10.1.4.1, 224.3.3.3) (192.1.1.1, 224.1.1.1) Prune List (192.1.4.2, 224.2.2.2) . . .
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

WC, RP WC, RP WC, RP RP (*, G) Join + NO (S, G)RP-bit Prunes = Non-Atomic Join

WC, RP RP

61 61

Example: Non-Atomic (*, G) Join


Also in this example, is a (*, G) entry for group 224.1.0.5 in the Join list of the PIM Join/Prune message. (The WC (wildcard) and RP (RP-Tree) bits tell us that this entry is a (*, G) Join to RP 10.1.4.1) In addition, there are no (S, G) entries for group 224.1.0.5 with the RP-bit set in the Prune list. (I.e. there are no (S, G)RP-bit Prunes for group 224.1.0.5). Because only a (*, G) Join exists in this Join/Prune message for group 224.0.1.5 without any corresponding (S, G)RP -bit Prunes, it is said to contain an NonAtomic (*, G) Join for group 224.0.1.5.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

61

RP on a Stick
Proxy Join Timer
Used on (S, G) entries only Started on the RP by the initial (S, G) Register
If (S, G) OIL is Null AND (*, G) OIL is Non-Null

Started/Restarted by receipt of a Non-Atomic Join


The X flag indicates when it is running Times out in 2 minutes

Controls the sending of (S, G) Joins and Prunes down the SPT When Proxy Join Timer is Running (X flag set)
Send (S, G) Joins down SPT Suppress sending any (S, G) Prunes down SPT
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

62 62

Proxy Join Timer


The Proxy Join Timer only exists on (S, G) entries in the Mroute table. Its purpose is to attract (S, G) traffic to the router even when the OIL of the (S, G) entry is Null. This maintains the flow of (S, G) traffic in cases such as the RPon-a-Stick.

Proxy Join Timer Rules


The Proxy Join Timer is started when the RP receives the first (S, G) Register message when a source goes active if: The OIL is null in resulting (S, G) entry AND the OIL is non-Null in the (*, G) entry. (This is the RP-on-a-Stick condition.) The Proxy Join Timer is started whenever the router receives a Non-Atomic (*,G) Join and an (S, G) entry already exists. This timer runs for 2 minutes unless restarted by the receipt of another NonAtomic (*, G) Join. When this timer is running on an (S, G) entry, the X flag will be displayed in the flags field of the entry. When the Proxy Join Timer is running, the router will: Send periodic (S, G) Joins toward the source even though the OIL is Null. Suppress the sending of (S, G) Prunes toward the source even though the OIL is Null.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

62

RP on a Stick

Header-only Registers
Used to keep (S, G) state alive in the RP Sent every 2 minutes by First-hop router
As long as source is still active Continues sending until a Register-Stop is received

Register Messages contains null (S,G) data packet


Processed by the RP Resets (S, G) entry timer at the RP RP doesnt send Null packet down Shared Tree

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

63 63

Header-only (Data-less) Registers


Normally, the Expire timer of an (S, G) entry is reset to 3 minutes every time the router forwards a packet associated with that entry. However, in the RP-on-aStick case, the (S, G) entry has a Null OIL and is therefore not forwarding any packets. This would normally result in the (S, G) entry timing out at the RP. This can not be allowed to happen as it is possible that another member somewhere in the network could join the Shared Tree via another interface. If the (S, G) entry was allowed to timeout, the RP would not be able to trigger the BatchJoin to rejoin the SPT when this new member joined. (Because there wouldnt be any (S, G) entry to tell the RP of the active source.) To prevent this from happening, the behavior of the First-Hop DR was changed in IOS 12.0 so that (S, G) Header-only (aka Data-less) Registers would be sent periodically (every 2 minutes) to the RP. These Header-only Registers cause the RP to reset the Expire timer in the (S, G) entry thereby preventing it from timing out.

Contents of Header-only Registers


Header-only Registers contain a specially formatted null or data-less (S, G) packet. These null (S, G) packets are not forwarded down the Shared Tree by the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

63

RP on a Stick
Non-Atomic Join Normal Register (S, G) Join

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: P PT XT Incoming interface: Ethernet0 Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list: Null

rtr-c
E0

192.1.1.1

Member 224.1.1.1

Trigger condition met: Proxy Join Timer started


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

64 64

RP-on-a-Stick Example
In this example, rtr-c is sending Non-Atomic (*, G) Joins to the RP to keep on the Shared Tree. (Note that rtr-c has not joined the SPT at this point. This could be due to the SPT-Threshold being set to Infinity.) The RP is now running version 12.0 or later of IOS. Therefore, when the NonAtomic (*, G) Join for group 224.1.1.1 is received, the RP starts the Proxy Join Timer in all (S, G) entries for group 224.1.1.1. This results in the following state in the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Notice the X flag is set in the above example. This causes the RP to continue sending (S, G) Joins toward the source (even though the OIL is Null) which, in turn, will keep the traffic flowing to the member across the common Ethernet segment.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

64

RP on a Stick
Periodic (S, G) Joins Header-only Registers

RP rtr-a
E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list:

rtr-c
E0

192.1.1.1

Member 224.1.1.1

Expiration Timer restarted by Header -only Registers


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

65 65

RP-on-a-Stick Example
The First-hop router (rtr-b) is also running version 12.0 or later of IOS and it will therefore send periodic Header-only (S, G) Register messages to the RP. When RP receives these Header-only (S, G) Registers, (roughly every 2 minutes), it resets the Expire timer in the corresponding (S, G) entry in the Mroute table. This results in the following state in the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: (Notice the Expire timer in the (S, G) entry has been reset.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

65

Turnaround Router

Extension of the RP-on-a-Stick Problem


Occurs when the SPT and the Shared Tree share a single common path Want to avoid pulling traffic to the RP unnecessarily

Special state in the Turnaround Router


Uses special techniques to resolve
Proxy Join Timer Atomic and Non-Atomic Joins Header-only Registers

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

66 66

Turnaround Router
As it turns out, the RP-on-a-Stick problem is actually a special case of another problem referred to the Turnaround Router problem. This situation occurs whenever : There is only a single branch of the Shared Tree and the Shared Tree and a SPT share a common path to the RP. We want to have the (S, G) traffic flow along the SPT toward the RP and turnaround at the appropriate router in the network and flow back down the Shared Tree without sending unnecessary traffic to the RP.

Turnaround Router Solution


Once again, the new concepts of Proxy Join Timer Atomic and Non-Atomic Joins Header-only Registers permit the routers to solve this problem.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

66

Turnaround Router
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
67 67

Turnaround Router Example


In this example, we once again have a single branch of the 224.1.1.1 Shared Tree at the RP. The SPT for source (192.1.1.1, 224.1.1.1) merges with the single branch of the 224.1.1.1 Shared Tree at rtr-x. This router is referred to as the Turnaround Router because it is here that we want the (S, G) traffic to turnaround and flow back down the Shared Tree to the members of group 224.1.1.1. Additionally, we do not want the (S, G) traffic flow to all the way to the RP as it is unnecessary traffic because there is only the single branch of the Shared Tree. In cases where the number of hops between the Turnaround Router and the RP is large or where the links along this path are congested, the flow of traffic to the RP would simply waste precious network resources. Instead, we want the traffic to only flow as shown by the thin dashed arrows in the drawing above.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

67

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

rtr-x Turnaround Router


E0 10.1.4.1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming 10.1.4.2 interface: E1 Null, RPF nbr 0.0.0.0, 10.1.4.3 E1 Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

E0

E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, Member 00:02:43/00:02:17

Source 192.1.1.1
Module6. ppt

224.1.1.1
68 68

1998 2001, Cisco Systems, Inc. All rights reserved.

Turnaround Router Step-by-Step


Step 1 The host connected to rtr-c joins group 224.1.1.1. This causes rtr-c to create (*, G) state and sends a Non-Atomic (*, G) Join toward the RP. Step 2 The Turnaround Router (rtr-x) receives this Non-Atomic (*, G) Join and it too creates (*, G) state and sends a Non-Atomic (*, G) Join to the RP. Step 3 The RP receives the (*, G) Join and creates (*, G) state with only Serial0 in the OIL.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

68

Turnaround Router
Non-Atomic Joins Normal Register

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, E0 RP 10.1.3.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-c
E0

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Serial0, RPF nbr 10.1.3.2, Source Member Outgoing interface list:

192.1.1.1

224.1.1.1
69 69

(S, G) Entry created & Proxy Join Timer started


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Turnaround Router Step-by-Step


Step 4 The source, 192.1.1.1, begins sending to group 224.1.1.1. This causes the first-hop router (rtr-b) to send an (S, G) Register to the RP. Step 5 The RP processes the Register message and creates an (S, G) entry. Because the OIL of the newly created (S, G) entry is Null and the OIL of the (*, G) entry is non-Null, the RP starts the Proxy Timer in the (S, G) entry and sends an (S, G) Join toward the source. At this point, the state in the RP is as follows: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list: Notice that the Proxy Join Timer is running (note the X flag in the (S,G) entry.) While the Proxy Join Timer is running, the RP will continue to send periodic (S, G) Joins toward the source. The Proxy Join Timer will be restarted each time the RP receives another Non-Atomic Join from rtr-x.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

69

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 10.1.3.1

(S, G) Joins S0 10.1.3.2

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: T Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Serial0, Forward/Sparse, 00:00:48/00:02:12

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
70 70

Turnaround Router Step-by-Step


Step 6 The (S, G) Join travels hop-by-hop building the SPT from the source to the RP. At this point, the state in the Turnaround Router (rtr-x) is as follows: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: T Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Serial0, Forward/Sparse, 00:00:48/00:02:12

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

70

Turnaround Router
Non-Atomic Joins

RP

rtr-a
S0 10.1.3.1

(S, G) Joins S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
71 71

Turnaround Router Step-by-Step


Once rtr-b receives the (S, G) Join, traffic begins to flow as shown above.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

71

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, Serial0, RPF nbr nbr 10.1.3.1 10.1.3.1, , Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: Ethernet0, RPF RPF nbr nbr 10.1.4.2, 10.1.4.2, Outgoing interface list: Serial0, Forward/Sparse, 00:00:48/00:02:12

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
72 72

Turnaround Router Step-by-Step


Step 7 Router rtr-x detects that the paths of the SPT and the Shared Tree diverge at this point. As a result, rtr-x begins sending periodic (S,G)RP-bit Prunes up the Shared Tree in the same Join/Prune message with the periodic (*, G) Joins. In other words, it begins sending Atomic Joins to the RP instead of Non-Atomic Joins! (Note: Router rtr-x knows that the SPT and Shared Tree paths have diverged at this point because the RPF information (Incoming Interface and/or RPF neighbor) of the (S, G) entry is different than the (*,G) entry.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

72

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-x Turnaround Router


E0 10.1.4.1

(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, 10.1.4.2 E1 list: 10.1.4.3 E1 Outgoing interface Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT PXT E0 Serial0, RPF nbr 10.1.3.2, E0 Incoming interface: Outgoing interface list:

Source 192.1.1.1
Proxy Join Timer eventually expires (Non-Atomic Joins no longer being received)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
73 73

Turnaround Router Step-by-Step


Because the RP is no longer receiving Non-Atomic Joins, the Proxy Join Timer for the (S, G) entry is no longer being restarted and it eventually times out. This is indicated by the X flag being clear in the (S, G) entry shown below: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list: Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

73

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins (S, G) Prunes (192.1.1.1, 224.1.1.1) Traffic Flow S0 10.1.3.2

RP

rtr-a
S0 10.1.3.1

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S E0 Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: interface: Ethernet0 Ethernet0, , RPF nbr 10.1.4.2, Outgoing interface list: Source Serial0, Forward/Sparse, 00:00:48/00:02:12 192.1.1.1

rtr-c
E0

Member 224.1.1.1
74 74

Serial0 removed from (S, G) OIL Trigger condition met


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Turnaround Router Step-by-Step


Step 8 Now that the Proxy Join Timer is no longer running, the RP resumes its normal behavior and sends an (S, G) Prunes toward the source in response to the arrival of (S, G) packets. Step 9 When rtr-x receives the (S, G) Prune, it removes Serial0 from its outgoing interface list. This results in the Turnaround trigger condition in rtr-x.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

74

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Join S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1

(Contains (*,G)Join + (S,G)RP-bit Prune)

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, E0 RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: P PT XT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list:

rtr-c
E0

192.1.1.1 Proxy Join Timer started by next non-Atomic Join.


Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
75 75

Turnaround Router Step-by-Step


As a result of Serial0 being removed from the (S, G) OIL, the flow of traffic to the RP is shutoff. Step 10 Non-Atomic Joins arriving at rtr-x now start the Proxy Join Timer. (Note the X flag in the (S, G) entry.) This causes the Turnaround Router (rtr-x) to suppress sending (S, G) Prunes and instead, send (S, G) Joins toward the source. This keeps the traffic flowing as shown.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

75

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

Final Steady-State Condition

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

rtr-b
E0 E0

rtr-c

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
76 76

Turnaround Router
Step 11 Finally, Header-only Registers sent by the First-hop router (rtr-b) continue to reset the Expire timer in the (S, G) entry at the RP. This prevents the (S, G) entry from timing out and being deleted at the RP.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

76

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

Final Steady-State Condition

rtr-x Turnaround Router


E0 10.1.4.1

(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: 10.1.4.2 E1 Null, RPF nbr 0.0.0.0, 10.1.4.3 E1 Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT E0 Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list:

E0

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
77 77

Turnaround Router
As a result of the Header-only Registers, the state in the RP will be as follows as long as the source and member remain active: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list:

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

77

Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow

RP

rtr-a
S0 10.1.3.1 S0 10.1.3.2

Final Steady-State Condition

rtr-x Turnaround Router


E0 10.1.4.1

10.1.4.2 E1

10.1.4.3 E1

(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17

rtr-b

rtr-c

(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list:

Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Member 224.1.1.1
78 78

Turnaround Router
As a result of the Non-Atomic Joins, the state in the Turnaround router will be as follows as long as the source and member remain active : (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list:

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

78

Module6. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

79

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module6.ppt

79

Advanced IP Multicast Features


Module 7

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

8/14/2001 10:15 AM

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

Module Objectives

Develop an understanding of the more advanced multicast features available in IOS.

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

2 2

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

Module Agenda

Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

3 3

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

BW Control via Rate-Limiting

IP multicast traffic can be rate-limited


Any data over the limit is discarded Rate-limit is on per second time slots Can rate-limit on input as well as output

Designed to
Deal with misbehaving sources Sharing bandwidth with unicast traffic

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

4 4

Bandwidth Control via Rate-Limiting


In general, concern over bandwidth utilization by multicast traffic is often more of an issue of FUD (Fear, Uncertainty, Doubt) than a real issue. However, like many other traffic types, multicast traffic can be rate-limited. Rates are measured over 1 second windows and compared to configured limits. Once the configured limit has been reached, further data that would exceed this limit is discarded. Rate-limiting may be applied to either incoming or outgoing traffic. Rate-limiting provides protection against: Misbehaving sources that are consuming too much bandwidth. Multicast consuming all of the available bandwidth.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

BW Control via Rate-Limiting

Interface-Based Rate-Limiting
Limits total rate of all multicast flows in/out of an interface

Flow-Based Rate-Limiting
Limits rate of each individual (S, G) or (*,G) flow in/out of an interface
Note: Both Interface and FlowFlow -based limits may not be used on an interface at the same time!

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

5 5

Interface-Based Rate-Limiting
Rate limits may be applied to the total overall rate of multicast traffic flowing into or out of an interface. This is the most commonly used form of multicast rate limiting, particularly for outgoing traffic. This permits an upper bound to be set on the bandwidth consumed by multicast traffic on an interface.

Flow-Based Rate-Limiting
Flow-based rate limits may be applied to an interface on a Group or Source/Group basis. When flow-based rate limits are defined, it causes the rate to be applied to the incoming or outgoing interface of matching (*, G) or (S, G) entries in the mroute table. For example, if an outgoing 50Kbps flow-based rate limit has been configured on interface Serial0 for (*, 224.1.1.1), then a 50Kbps rate limit will be set on Serial0 whenever it appears in the OIL of any (*, 224.1.1.1) or (S, 224.1.1.1) mroute table entries. This will limit the rate of each these flows to a maximum of 50Kbps. Note: Flow-based rate limiting is applied independently to each individual flow. In the above example, this would limit each individual matching flow out Serial0 to 50Kbps. It would not rate limit the total flow of 224.1.1.1 traffic out Serial0 to 50Kbps. Therefore, if there were several sources for the 224.1.1.1 group, the total flow can easily exceed 50Kbps. Keywords such as video and whiteboard may be used to further identify media specific flows on a UDP port basis. However, for this to work, ip sdr listen must be configured so that the router can obtain the necessary SDR session information to identify which flows are video and which are whiteboard.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

BW Control via Rate-Limiting


Rate limit interface command
ip multicast rate-limit in | out { [video] | [whiteboard] } [group-list <acl>] [source-list <acl>] [<kbps>]

An Interface-based rate limit is defined when the optional Group and/or Source ACLs are not used. A Flow-based rate limit is defined when the optional Group and/or Source ACLs are used
Multiple Flow-based entries may be used per interface Flow-based and Interface -based limits may not be used at the same time

Typical Rate-Limit Application


Use out form of command on WAN links Set <kbps> to desired percentage usage of link BW
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

6 6

Rate-Limit Interface Command


The format of the rate-limit interface command is shown above. The in and out keywords are used to specify if the rate-limit is to be applied to incoming or outgoing multicast traffic, respectively. An interface-based rate-limit is defined when the optional group-list and/or source-list ACLs are NOT used. Only one in and one out interfacebased rate limit may be defined on an interface. A flow-based rate-limit is defined when either the group-list or source-list ACLs are specified. Multiple flow-based rate-limit commands may be configured on an interface When an interface is added to the outgoing interface list or becomes the incoming interface, the list of rate-limits configured for that interface are searched for a match as follows: All rate-limits configured on an interface are maintained and searched in the order in which they were entered. If the interface is being used as the incoming interface for the mroute table entry the list is searched for an in limit. If the interface is being added to the outgoing interface list of the mroute entry, the list is search for an out limit. The list is searched for the first rate-limit that matches the optional group and source ACL. (if there was no group or source ACL specified, then the limit is an interface-based limit and the limit matches unconditionally.) The appropriate limit (interface or flow) is configured for the interface. The most typical usage for rate-limits is to configure out interface-based limits on WAN links where the value of <kbps> is set to some desired percentage of the overall WAN link bandwidth. This prevents misbehaving multicast sessions from consuming all of the link bandwidth.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

BW Control via Rate-Limiting


Limiting video or whiteboard streams
Add video or whiteboard keywords Requires ip sdr listen to be enabled Streams identified using info from sdr cache Example:
Listening to IETF broadcast behind a 128kbps link Theyre sending video at 128kbps and audio at 64kbps

Requirements
Want crystal clear audio Want good response to data actions (interactive) Marginal video acceptable

Configuration
interface serial 0 ip multicast rate-limit out video 48

Router will differentiate UDP port numbers for the same group
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

7 7

Limiting Video or Whiteboard Streams


Keywords such as video and whiteboard may be used to further identify media specific flows on a UDP port basis. For this to work, ip sdr listen must be configured so that the router can obtain the necessary SDR session information to identify which flows are video and which are whiteboard. The router actually uses the SDR session information to identify the multicast group and UDP port number that is being used to send v ideo or whiteboard data. In the example above, the upstream serial interface is configured so that video can only consume 48kbps of the 128kbps ISDN line. This permits the 64kbps audio to be sent without experiencing any loss due to the video stream over subscribing the line.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29, Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25, . . .

Interface -based Output Rate-limit

Total output multicast traffic rate on Serial0 will not exceed 512 Kbps. Kbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

8 8

Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output interface-based rate-limits are shown on the entries in the outgoing interface list (OIL) of each mroute table entry. The text following the OIL will have the word Int preceding the rate limit value indicating that this is an Interface-based limit. In the example above, an output interface-based rate-limit of 512kbps has been configured on interface Serial0.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29 Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25 . . .

Interface -based Input Rate -limit

Total input multicast traffic rate on Ethernet0 will not exceed 1 Mbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

9 9

Debugging Rate-Limits
Rate-limits may be displayed via the show ip mroute command. Input interfacebased rate-limits are shown on the incoming interface of each mroute table entry. The text following the incoming interface information will have the word Int preceding the rate limit value indicating that this is an Interface-based limit. In the example above, an input interface-based rate-limit of 1 Mbps has been configured on interface Ethernet0.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29 Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25 . . .

Flow-based Output Rate-limit

Each individual output multicast flow on Serial1 will not exceed 56 Kbps. The total output on Serial1 is the sum of all flows and can exceed 56Kbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

10 10

Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output flowbased rate-limits are shown on the entries in the outgoing interface list (OIL) of each mroute table entry. The text following the OIL will be missing the word Int preceding the rate limit value. This indicates that this is an flow-based limit. In the example above, an output flow-based rate-limit of 56kbps has been configured on interface Serial1. NOTE: Each individual matching flow will be rate-limited to 56kbps, not the total aggregate of all matching flows. This means that if there are 10 active flows that match the configured flow-based rate-limit, the total aggregate rate out Serial1 could be as high as 560kbps!

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

10

BW Control via Rate-Limiting


Example: FlowFlow-based RateRate-Limiting
Video Server 1 (192.1.1.1, 224.1.1.1)
interface serial0 ip multicast rate-limit out group-list 10 100 access-list 10 permit 224.1.1.1

128 Kbps E0 Video Server 2 (192.2.2.2, 224.1.1.1) S0 E1 128 Kbps


(192.1.1.1, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Limit 100 kbps (192.2.2.2, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet1, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Limit 100 kbps
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

100 Kbps

Total: 200 Kbps


100 Kbps

11 11

Flow-based Rate-Limiting Example


In the above example, there are two 128kbps sources of video being sent to group 224.1.1.1 which in turn, flow through the 7500 router and out Serial0 to downstream receivers (not shown). Interface Serial0 is configured with an output flow-based rate limit of 100kbps (as shown in the configuration excerpt). The output of a show ip mroute command clearly shows that this output flowbased rate limit has been applied to Serial0 for both sources. The results will be that each video flows will be rate-limited to a maximum of 100kbps, thereby causing drops in the multicast video streams.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

11

BW Control via Rate-Limiting


Example: FlowFlow-based RateRate-Limiting
Video Server 1 (192.1.1.1, 224.1.1.1)
interface serial0 ip multicast rate-limit out group-list 10 200 access-list 10 permit 224.1.1.1

128 Kbps E0 Video Server 2 (192.2.2.2, 224.1.1.1) S0 E1 128 Kbps


(192.1.1.1, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Limit 200 kbps (192.2.2.2, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet1, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Limit 200 kbps
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

128 Kbps

Total: 256 Kbps!!!


128 Kbps

12 12

Flow-based Rate-Limiting Example


Continuing with the same example, interface Serial0 is now reconfigured with an output flow-based rate limit of 200kbps (as shown in the configuration excerpt). The output of a show ip mroute command clearly shows that this output flowbased rate limit has been applied to Serial0 for both sources. The results will be that neither video flow will be rate-limited since their maximum streaming speed is only 128kbps. This results in a total aggregate rate of 256kbps for both flows. Note that this rate-limit will NOT limit the total aggregate flow rate of these matching flows to a maximum of 200kbps as might be expected by some network engineers.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

12

BW Control via Rate-Limiting


Example: InterfaceInterface-based Rate Limiting
Video Server 1 (192.1.1.1, 224.1.1.1)
interface serial0 ip multicast rate-limit out 200

128 Kbps E0 Video Server 2 (192.2.2.2, 224.1.1.1) S0 E1 128 Kbps


(192.1.1.1, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int Limit 200 kbps (192.2.2.2, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Ethernet1, RPF nbr 0.0.0.0 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int Limit 200 kbps
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

??? Kbps

Total: 200 Kbps


??? Kbps

13 13

Interface-based Rate-Limiting Example


Finally, interface Serial0 is once again reconfigured with an output interfacebased rate limit of 200kbps (as shown in the configuration excerpt). The output of a show ip mroute command clearly shows that this output interface-based rate limit has been applied to Serial0 for both sources. The results will be that all multicast traffic (including these two video flows) will be rate-limited to a total aggregate rate of 200kbps. Note that this rate-limit results in potential loss for both flows since the combined rate of the two flows exceeds the 200kbps output interface limit.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

13

BW Control via Rate-Limiting

Summary
Flow-based rate-limits do not limit the total aggregate of all the matching flows. Therefore, the use of interfacebased rate-limits are recommended when an upper bound on multicast traffic rates is desired.

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

14 14

Summary
Flow-based rate-limits generally do not provide the sort of rate-limiting that is very useful in real-world networks. As a result, only interface-based rate-limits are normally used when an upper bound on multicast traffic is desired.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

14

BW Control via Admin-Scoping


Limit high-BW source to local site Use administratively-scoped zones
Simple scoped zone example:
239.192.0.0/16 = Site-Local Scope Zone 239.0.0.0/8 = Org.-Local Scope Zone 224.0.1.0 - 238.255.255.255 = Global scope (Internet) zone

High-BW sources use only site-local zone groups Med.-BW, org-wide sources use org.-local zone Low-Med. BW, Internet-wide sources use global zone
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

15 15

BW Control via Admin Scoping


Another method that can be used to control the BW usage by multicast traffic is to employ Admin-Scoped zones along with corresponding multicast boundaries. This allows one to restrict high-rate multicast flows from leaving certain geographical boundaries where bandwidth is plentiful, and going out over bandwidth constrained WAN links. In the above example, the following Admin Scoped ranges are in use Site-Local Scope Global Scope (Internet) - 239.192.0.0/16 - 224.0.1.0 - 238.255.255.255 Organization-Local Scope (Company?) - 239.0.0.0/8 High BW, Site-Local sources should always use a group address in the SiteLocal Scope. Medium BW, Organization-Local sources should always use a group address in the Organization-Local Scope. Sources that wish to transmit to the Internet should use group addresses that do not fall in either the Site-Local or Organization-Local scopes.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

15

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A

S0

S1

T1
S0

T1
S0

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
16 16

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
In this example, two remote sites (Los Angeles and Atlanta) are linked to the company HQ site via T1 lines. Each of the three sites has its own Mapping Agent and a Site-Local RP that serves the Site-Local group range 239.192.0.0/16 that was described in the previous slide. This is necessary since the goal is to keep all Site-Local traffic within each site and therefore each site must have its own independent RP for this group range.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

16

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A

Org-Local Boundary Site -Local Boundaries


T1
S0

Site -Local Boundaries


T1
S0

S0

S1

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
17 17

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
The first step is to establish multicast boundaries that prevent Site-Local and Organization-Local multicast traffic from crossing certain boundaries. In the case of Site-Local traffic, these boundaries are established on the T1 links on each of the three border routers, A, B and C. The Site-Local boundaries are implemented using the ip multicast boundary interface command along with an access-control list that denies multicast traffic in the Site-Local group range (239.192.0.0/16) from crossing this boundary. The Organization-Local boundary is established on the link to the internet and is also implemented using the ip multicast boundary interface command. The access-control list for this boundary denies multicast traffic in the Organization-Local group range (239.0.0.0/8) from crossing this boundary.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

17

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10

Site Local RP/MA

S0

access-list 10 deny 239.192.0.0 0.0.255.255 access-list 10 permit any

Border A

Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 access-list 10 deny 239.192.0.0 0.0.255.255 access-list 10 permit any

S0

S1

T1
S0

T1
S0

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
18 18

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
The configuration commands necessary to establish the Site-Local boundaries on border routers B and C are listed in the above drawing. In both configurations, the Site-Local boundary is established on interface Serial0 via the ip multicast boundary 10 interface command. Access-control list 10 is constructed to deny the passage of any traffic in the Site-Local group range (239.192.0.0/16) while all other multicast groups are permitted to cross the interface. Pay particular attention to the ip multicast ttl-threshold 16 command also configured on Serial0. The requirement for this command will be discussed in a later slide.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

18

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A

S0

S1

T1
Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 Interface Serial1 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 Site Local access-list 10 deny 239.192.0.0 0.0.255.255 access-list 10 permit any

T1

S0

S0

Border B

Border C

RP/MA

Site Local RP/MA

Site B (LA)

Site C (ATL)
19 19

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
The configuration commands necessary to establish the Site-Local boundaries on border router A are listed in the above drawing. In this case, the Site-Local boundary is established on both interface Serial0 and Serial1 via the ip multicast boundary 10 interface command. Access-control list 10 is constructed to deny the passage of any traffic in the Site-Local group range (239.192.0.0/16) while all other multicast groups are permitted to cross the interface. Again notice the ip multicast ttl-threshold 16 command also configured on Serial0 and Serial1. The requirement for this command will be discussed in a later slide.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

19

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
interface Loopback0 Site Local ip address 192.168.10.2 255.255.255.255 RP/MA ip pim send-rp-discovery Loopback0 scope 15 ip pim send-rp-announce Loopback0 scope 15 group 20 access-list 20 permit 239.192.0.0 0.0.255.255

S0

Border A

S0

S1

T1
S0

T1
S0

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
20 20

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
The next step is to configure the independent Mapping Agents for each site as well as the independent Site-Local group RP. In the drawing above, the configuration for the RP/Mapping Agent in Site B is shown. In this case, interface Loopback0 has been configured for use as the interface of choice for the Mapping Agent and RP. A loopback interface is often used for this purpose as it provides more flexibility in the management of the Mapping Agent as well as the selection of the RP when multiple candidate RPs are define. (The highest candidate IP address is chosen as the active RP by Mapping Agents.) The ip pim send-rp-discovery global command defines the router as a Mapping Agent for Site B with an IP address of the loopback interface. Note that a TTL scope of 15 is used on this command so that the Discovery messages sourced by this Mapping Agent will not exit the Site. (This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) The ip pim send-rp-announce global command along with accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site B as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

20

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0
interface Loopback0 ip address 192.168.10.1 255.255.255.255

Border A

ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 group 20 access-list 20 permit 239.192.0.0 0.0.255.255 S0

S1

T1
S0

T1
S0

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
21 21

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
In the drawing above, the configuration for the RP/Mapping Agent in Site C is shown. Interface Loopback0 has also been configured for use as the interface of choice for the Mapping Agent and RP. The ip pim send-rp-discovery global command defines the router as a Mapping Agent for Site C with an IP address of the loopback interface. Note once again that a TTL scope of 15 is used on this command so that the Discovery messages sourced by this Mapping Agent will not exit the Site. (This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) The ip pim send-rp-announce global command along with accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site C as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

21

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A

S0

S1

T1

S0 interface Loopback0 Border B 255.255.255.255 Border C ip address 192.168.10.3


ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 group 20 access-list 20 permit 239.192.0.0 0.0.255.255

T1
S0

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
22 22

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
In the drawing above, the configuration for the RP/Mapping Agent in Site A is shown. Interface Loopback0 has also been configured for use as the interface of choice for the Mapping Agent and RP. The ip pim send-rp-discovery global command defines the router as a Mapping Agent for Site A with an IP address of the loopback interface. Note once again that a TTL scope of 15 is used on this command so that the Discovery messages sourced by this Mapping Agent will not exit the Site. (This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) The ip pim send-rp-announce global command along with accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site A as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

22

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A

S0

T1

Main RP/MA (non-Site Local Groups)


S0

interface Loopback0 S0 ip address 192.168.1.3 Border B255.255.255.255 Border C ip pim send-rp-discovery Loopback0 scope 64 ip pim send-rp-announce Loopback0 scope 64 group 20 ip pim rprp -announce announce-filter rprp -list 10 access accesslist 10 deny 192.168.10.3 Site Local accessaccess -list 10 permit any

S1
T1

RP/MA

Site Local RP/MA

access-list 20 permit 224.0.0.0 0.255.255.255 access-list 20 permit 225.0.0.0 0.255.255.255 . . . access-list 20 permit 238.0.0.0 0.255.255.255
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

Site B (LA)

Site C (ATL)
23 23

Admin-Scoping Example
Next, an RP for all the non-Site-Local multicast groups must be configured. Border router A has been chosen for this task. Additionally, router A is configured as a Mapping Agent with sufficient scope to cover the entire network. (Note: The independent Mapping Agents for each site make this step unnecessary as they can handle the Mapping Agent functionality for their site.) Once again, interface Loopback0 has been configured for use as the interface of choice for the Mapping Agent and RP. The ip pim send-rp-announce global command along with accesscontrol list 20, defines the router as a Candidate RP for all non-Site-Local groups. Note that a TTL scope of 64 is used on this command so that the Announce messages sourced by this Candidate-RP will reach all routers in all Sites. The ip pim send-rp-discovery global command defines the router as a Mapping Agent for the entire network. Note that a TTL scope of 64 is also used on this command so that the Discovery messages sourced by this Mapping Agent reach all routers in all Sites. Because the scope of the Discovery messages are 64, they will reach all routers in all sites. Therefore, care must be taken to insure that the C-RP information from the Site-Local C-RP in the HQ site is not accepted and inadvertently advertised in Discovery messages by the Mapping Agent. If this were to occur, the routers in the other site(s) might select the Candidate-RP in the HQ Site as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site. To prevent this from happening, the ip pim rp-announce-filter command along with access-control list 10 is used to filter out C-RP Announcement messages from the Site-Local C-RP in the HQ Site. Note: This problem can be avoided if router A is not configured as a Mapping Agent.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module7.ppt 23

BW Control via Admin-Scoping


Site A (HQ)
AS Border

To Internet
Site Local RP/MA
S0

Border A
Interface Serial0 . . . S0 ip multicast ttl-threshold 128 ip multicast boundary 10

S1

T1

access-list 10 deny 239.0.0.0 0.0.0.255 access-list S0 10 permit any

T1

S0

Border B

Border C

Site Local RP/MA

Site Local RP/MA

Site B (LA)
Module7. ppt

Site C (ATL)
24 24

1998 2001, Cisco Systems, Inc. All rights reserved.

Admin-Scoping Example
Finally, the AS Border router must be configured with a multicast boundary so that all locally scoped multicast traffic in the 239.0.0.0/8 range is blocked from entering or leaving the company. In this configuration, the multicast boundary is established on interface Serial0 via the ip multicast boundary 10 interface command. Access-control list 10 is constructed to deny the passage of any traffic in the Admin-Scoped group range (239.0.0.0/8) while all other multicast groups are permitted to cross the interface. Although it is not necessary to implement Admin-Scoping, the ip multicast ttl-threshold 128 command is also configured on Serial0 of the AS border router. This is often used to provide TTL scoping of traffic inside of the company. Sources that do not wish to have their multicast traffic leave the company can transmit with a TTL less than 128 and be insured that the traffic will not be forwarded into the Internet.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

24

Module Agenda

Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

25 25

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

25

Non-Congruent Networks

Why would you have non-congruent unicast & multicast networks?


Multicast is not enabled on all paths in the network Tunnels are used to bypass normal unicast routing You have policy reasons for making them different You want to use idle links for multicast traffic

Non-congruent unicast/multicast networks


RPF Calculation cannot use unicast route table Other source of RPF information must be used

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

26 26

Non-congruent Multicast/Unicast Networks


There are several cases were it might be desirable for Unicast and Multicast traffic to follow separate paths through a network. Some of these cases are: When multicast is not enabled on all interfaces of a router. When tunnels are in use to bypass unicast-only sections of a network. There exists some policy that dictates that multicast traffic follow different paths. It is desirable for multicast traffic to flow over idle/backup links for better load balancing. When the unicast and multicast networks are not congruent, certain limitations come into play, such as: The RPF calculation cannot use the unicast routing table since that would cause the unicast and multicast networks to be congruent by default. Some other source of information than the unicast routing table must be used. This imposes additional configuration and administration requirements that (in many cases) are non-trivial.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

26

PIM RPF Calculation Details


Decreasing Preference Static Mroute Table
(First Match)

Route/Mask, Dist.
(Default Dist. = 0)

(Best Path)

RPF Calculation (Use best Distance unless Longest Match1 is enabled. If enabled, use longest Mask.)

BGP MRIB

Route/Mask, Dist.
(eBGP Def. Dist.=20) (iBGP Def. Dist.=200) (Longest Match)

IIF, RPF Neighbor

DVMRP Route Table

Route/Mask, Dist.
(Default Dist. = 0)

Unicast Routing Table


Module7.ppt

(Longest Match)

Route/Mask, Dist.
1 Global Command:

ip multicast longest-match
27 27

1998 2001, Cisco Systems, Inc. All rights reserved.

PIM RPF Calculations


Cisco IOS permits other sources of information to be used in the RPF calculation other than the unicast routing table. In general, these other sources are preferred based on their Admin. Distance. If Admin Distance values are equal, the sources are preferred in the order listed below: Static Mroute Table Static Mroutes may be defined that are local to the router on which they are defined. If a matching Static Mroute is defined, its default Admin. Distance is zero and is therefore preferred over other sources. (If another source also has a distance of zero, the Static Mroute takes precedence.) BGP Multicast RIB (M-RIB) If MBGP is in use and a matching prefix exists in the MBGP M-RIB, it will be used as long as its Admin. Distance is the lowest of the other sources. (MBGP M-RIB prefixes are preferred over DVMRP or Unicast routes if the Admin Distances are the same.) DVMRP Route Table If DVMRP routes are being exchanged and there exists a matching route in the DVMRP route table, the default Admin. Distance of this route is zero. DVMRP routes are preferred over Unicast routes if their Admin. Distances are equal. Unicast Route Table This is least preferred source of information. If no other source has a matching route with a lower Admin. Distance, then this information is used.
Note: The above behavior can be modified so that the longest match route is used from the available sources. This is configured with the ip multicast longest-match hidden command.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

27

Alt. Path Routing with Static Mroutes


Statically configured using command:
ip mroute <source> <mask> [<protocol>][route-map <map>] <rpf-nbr> | <interface> [<distance>]

Multiple mroutes may be specified


Searched in order of configuration Search stops on first match and route is used Admin distance of mroute compared to other routes

Mroutes have a default distance of zero


Preferred over all other routes by default

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

28 28

Static Mroutes
A Static Mroute may be configured using the command listed above to match based on the <source> and <mask> parameters. Either an <rpf-nbr> address or a specific <interface> can be configured as the next-hop. An optional <protocol> may be configured which requires that a matching route must exist in the specified unicast routing protocols database for the Static Mroute to match. An optional route-map <map> clause may be configured to constrain the match to the qualifications specified in the route-map in order for the Static Mroute to match. The default Admin. Distance of a Static Mroute is zero. This value may be overridden by the use of the <distance> parameter. If multiple Static Mroutes are configured, they are searched for a match in the order in which they were configured. If a match is found, the search terminates and the Static Route is used if it has an Admin. Distance less than or equal to any other source of RPF information. Note: Unlike their unicast counterparts, Static Mroutes only have significance on the router on which they are defined and cannot be redistributed.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

28

Alt. Path Routing with Static Mroutes

A stub connection where you have a tunnel for multicast access


ip mroute 0.0.0.0 0.0.0.0 tunnel0 Central Site tunnel0 MR UR

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

29 29

Static Mroute: Example 1


In this example, a multicast router (MR) has been configured with a tunnel to a multicast router outside of the network so that it can receive multicast traffic. The ip mroute 0.0.0.0 0.0.0.0 Tunnel0 command instructs router MR to RPF to Tunnel0 for all multicast sources instead of using the unicast routing information. Therefore, any multicast traffic arriving via Tunnel0 will be RPF correctly using this Static Mroute. If this Static Mroute was not used, router MR would us the unicast routing information which would cause it to RPF to router UR instead of Tunnel0 for traffic arriving from the outside of the network. Note: While this is a simple way to force router MR to RPF to the tunnel for traffic arriving from outside of the network, traffic arriving at MR from sources inside the network will RPF fail. This is because the source/mask covers all multicast sources, both inside and outside of the network. Obviously, a more sophisticated solution is required. (See next slide.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

29

Alt. Path Routing with Static Mroutes

You want to tailor RPF for many routes


ip mroute 0.0.0.0 0.0.0.0 ospf 1 null0 255 ip mroute 0.0.0.0 0.0.0.0 tunnel0
Central Site
OSPF Domain

tunnel0

MR UR

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

30 30

Static Mroute: Example 2


In this example, the multicast router (MR) has been reconfigured so that only traffic arrving from outside the network will RPF to Tunnel0 while traffic arriving from sources inside the OSPF domain will RPF correctly. An additional Static Mroute command ip mroute 0.0.0.0 0.0.0.0 ospf 1 null0 255 is configured ahead of the original Static Mroute used in the previous example. The command instructs router MR to match on any multicast source that has a corresponding matching entry in the OSPF 1 process database. For these matching sources, the RPF interface is set to Null0 and the Admin. Distance of the Static Mroute is set to 255. The second (and original) ip mroute 0.0.0.0 0.0.0.0 Tunnel0 command instructs router MR to RPF to Tunnel0 for all multicast sources just as was done in the previous example. However, since this command appears second in the configuration, it will only be reached if the first command fails to match (i.e. the source is not inside the OSPF domain). Exactly how these two commands combine to achieve the desired result may not be immediately obvious and is therefore described below: Sources outside the OSPF domain: Will not match on the first Static Mroute in the list since there is no matching route in the OSPF database. However, the second Static Mroute will match with an RPF interface of Tunnel0 and an Admin. Distance of zero. Therefore, these sources will RPF to Tunnel0. Sources inside the OSPF domain: Will match on the first Static Mroute because there is a matching route in the OSPF database and the search of the Static Mroutes terminates with an RPF interface of Null0 and an Admin. Distance of 255. However, since the unicast routing table will also have a matching OSPF route with a lower (better) Admin. Distance than 255, the route in the unicast routing table will be used. Therefore, the router will RPF to the correct interface for this source inside the OSPF domain.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module7.ppt 30

Alt. Path Routing with DVMRP

Use DVMRP routes for RPF Check


Permits separate unicast & multicast topologies Can use some unicast routes and some routes from the DVMRP table DVMRP routes are preferred by default
Default DVMRP Distance = 0

Warning!
Care must be used to prevent route redistribution problems

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

31 31

Using DVMRP Routes


As shown in the slide on RPF Details, DVMRP routes can be used as an alternate source of RPF information which, in turn, can be used to provide separate unicast and multicast topologies. The default Admin. Distance of DVMRP routes (zero) makes them preferred over routes in the unicast route table. (In the case of a tie in Admin. Distance values, a DVMRP route is preferred over a unicast route for RPF calculation.) Just as in unicast redistribution scenarios, care must be taken to avoid route loops from occurring when exchanging DVMRP routes between Cisco routers. This is due to the fact that unicast routes are automatically injected into DVMRP by default. This redistributing can cause multicast route loops or RPF failures to occur.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

31

Alt. Path Routing with DVMRP


ip dvmrp unicast-routing causes DVMRP routes to be exchanged between two Cisco routers.
PIM Router DVMRP Route Table Unicast Route Table

ip dvmrp unicast-routing

DVMRP Routes*

PIM Router * Split-Horizon is used between two Cisco


routers.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

DVMRP Route Table

Unicast Route Table

32 32

Using DVMRP Routes


The ip dvmrp unicast-routing interface command instructs a Cisco router to begin sending and receiving DVMRP routes on the interface. When two Cisco routers are connected via interfaces that have this command configured (such as in the example above), they will: Receive DVMRP route reports and install them in their DVMRP route table using standard DVMRP metrics. Send DVMRP route reports from the routes contained in their DVMRP route table. Inject certain selected routes from the unicast routing table in DVMRP route reports. By default, only connected routes are injected in these DVMRP route reports. However, additional routes may be injected from the unicast routing table. (See next slide.) Note: When two Cisco routers are exchanging DVMRP route reports, the normal DVMRP Poison-Reverse mechanism is not used. Instead, Split-Horizon is used so that DVMRP routes are not advertised back out interface from which they were received.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

32

Alt. Path Routing with DVMRP


Injecting ALL routes using the ip dvmrp metric command
DVMRP Routes 151.16.0.0/16, M=8 172.34.15.0/24, M=11 202.13.3.0/24, M=9 176.32.10.0/24, M=1 176.32.15.0/24, M=1 176.32.20.0/24, M=1 . . . (10,000 Routes!) interface Tunnel 0 ip unnumbered Ethernet 0 ip dvmrp metric 1 ... interface E0 ip addr 176.32.10.1 255.255.255.0 ip pim sparse-dense-mode interface E1 ip addr 176.32.15.1 255.255.255.0 ip pim sparse-dense-mode

Tunnel
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)

DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0

E0

E1

176.32.10.0/24 176.32.15.0/24 Always Use an Access - List with the ip dvmrp metric Command
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

33 33

Using DVMRP Routes - Injecting unicast routes


The default behavior of a Cisco router is to inject only connected routes. However, the ip dvmrp metric interface command can be used to modify this behavior. When this command is used without an access-control list, ALL routes in the unicast routing table will be injected into DVMRP route reports. An example of this is shown In the drawing above. The ip dvmrp metric 1 command results in the entire unicast routing table being injected into DVMRP route reports with a metric of 1. In most cases, this is not desirable and an access-control list should be used to limit which routes are injected.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

33

DVMRP Redistribution Problem


Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.1.0/24 S0 45106272 45106272 90 90 172.16.1.0/24 S0 172.16.20.0/24 S0 S0 45126319 45126319 90 90 172.16.20.0/24 Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.1.0/24 S1 45034510 45034510 90 90 172.16.1.0/24 S1 172.16.20.0/24 S1 S1 45085628 45085628 90 90 172.16.20.0/24

ip dvmrp unicast-routing ip dvmrp metric 1


172.16.10.0/24

Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

C
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

34 34

DVMRP Redistribution Problem


As previously stated, care must be taken to avoid redistribution problems when DVMRP routes are being exchanged between Cisco routers. This example demonstrates what can happen if careful attention to route injection is not observed. The drawing above shows two Cisco routers (along with their unicast route table) connected via a GRE Tunnel which is being used to tunnel through a unicast-only cloud. At each end of the tunnel, ip dvmrp unicast-routing has been enabled and the entire set of routes from the unicast routing table is being injected into DVMRP route reports with a metric of 1 by the use of the ip dvmrp metric 1 command.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

34

DVMRP Redistribution Problem


Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.1.0/24 S0 45106272 45106272 90 90 172.16.1.0/24 S0 172.16.20.0/24 S0 S0 45126319 45126319 90 90 172.16.20.0/24

172.16.10.0/16, 172.16.15.0/24, 172.16.1.0/24, 172.16.20.0/24 ...

M=1 M=1 M=1 M=1

All Unicast routes are advertised as DVMRP routes as a result of the ip dvmrp metric 1 command.

DVMRP Report 172.16.10.0/24


Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

C
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

35 35

DVMRP Redistribution Problem


The drawing above shows router A injecting its entire set of unicast routes into a DVMRP report, each with a metric of 1.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

35

DVMRP Redistribution Problem


DVMRP Route Route Table Table DVMRP Network Intf Metric Network Intf Metric 172.16.10.0/24 Tun0 Tun0 2 172.16.10.0/24 2 172.16.15.0/24 Tun0 Tun0 2 172.16.15.0/24 2 172.16.1.0/24 Tun0 Tun0 2 172.16.1.0/24 2 172.16.20.0/24 Tun0 Tun0 2 172.16.20.0/24 2 Dist Dist 0 0 0 0 0 0 0 0 Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.1.0/24 S1 45034510 45034510 90 90 172.16.1.0/24 S1 172.16.20.0/24 S1 S1 45085628 45085628 90 90 172.16.20.0/24

Preferred Route

Module7. ppt

DVMRP Redistribution Problem


As a result, router B has installed these DVMRP routes in its DVMRP route table with the appropriate metrics. Router B will now prefer the DVMRP route for network 172.16.1.0/24 over the same unicast route since the DVMRP route has an Admin Distance of zero. Now assume that the source begins to send multicast traffic which arrives at router B via interface Serial1. Unfortunately, this traffic will RPF Fail because the preferred DVMRP route indicates that the correct RPF interface for this traffic is Tunnel0.

172.16.10.0/24

Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

RPF Failure!

Source
1998 2001, Cisco Systems, Inc. All rights reserved.

C
36 36

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

36

DVMRP Redistribution Problem


Correct Configuration
interface Tunnel0 Tunnel0 interface ip address address <address> <address> <mask> <mask> ip ip dvmrp dvmrp unicast-routing unicast-routing ip ip dvmrp dvmrp metric metric 1 1 list list 10 10 ip access-list 10 10 access-list permit 172.16.15.0 172.16.15.0 permit permit 172.16.10.0 172.16.10.0 permit 0.0.0.255 0.0.0.255 0.0.0.255 0.0.0.255

Module7. ppt

Solution to DVMRP Redistribution Problem


The correct way to configure router A is to use an access-control list on the ip dvmrp metric command that specifies only those networks behind router A. (In this case, networks 172.16.15.0/24 and 172.16.10.0/24.)

172.16.10.0/24

Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

Source
1998 2001, Cisco Systems, Inc. All rights reserved.

C
37 37

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

37

DVMRP Redistribution Problem


Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.1.0/24 S0 45106272 45106272 90 90 172.16.1.0/24 S0 172.16.20.0/24 S0 S0 45126319 45126319 90 90 172.16.20.0/24

Only selected Unicast routes are advertised as DVMRP routes as a result of the new acl on the ip dvmrp metric 1 command.
172.16.10.0/24, M=1 172.16.15.0/24, M=1

DVMRP Report 172.16.10.0/24


Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

Source
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

C
38 38

Solution to DVMRP Redistribution Problem


Using this new configuration, we now see that router A is only injecting networks 172.16.10.0/24 and 172.16.15.0/24 in DVMRP route reports that are sent to router B.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

38

DVMRP Redistribution Problem


Preferred Route
DVMRP Route Route Table Table DVMRP Network Intf Metric Network Intf Metric 172.16.10.0/24 Tun0 Tun0 2 172.16.10.0/24 2 172.16.15.0/24 Tun0 Tun0 2 172.16.15.0/24 2 Unicast Route Route Table Table Unicast Network Intf Metric Dist Dist Network Intf Metric 172.16.1.0/24 S1 45034510 45034510 90 90 172.16.1.0/24 S1 172.16.10.0/24 E0 E0 10514432 10514432 90 90 172.16.10.0/24 172.16.15.0/24 E1 E1 10512012 10512012 90 90 172.16.15.0/24 172.16.20.0/24 S1 S1 45085628 45085628 90 90 172.16.20.0/24

Dist Dist 0 0 0 0

Module7. ppt

Solution to DVMRP Redistribution Problem


As a result, router B has installed only these two DVMRP routes in its DVMRP route table with the appropriate metrics. Now when router B receives traffic from the source on network 172.16.1.0/24, it will only find this route in its unicast routing table and will use this information to correctly calculate the RPF interface as Serial1. This will allow the RPF check to succeed for traffic arriving from the source.

172.16.10.0/24

Tun 0 E0

GRE Tunnel

Tun 0 S0

A
E1

S0

B
S1

172.16.15.0/24 172.16.1.0/24

RPF Succeeds!

Source
1998 2001, Cisco Systems, Inc. All rights reserved.

C
39 39

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

39

Alt. Path Routing with DVMRP


Either must make careful use of ACLs
Use ACL on all ip dvmrp metric commands
To prevent route loops and RPF problems. Complex problem to administer. ACLs may prevent network from converging after a failure.

Or run DVMRP everywhere!


Results in ships-in-the-night routing
Enable dvmrp unicast-routing on every interface Inject only connected routes (default)
i.e. Dont use ip dvmrp metric command
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

40 40

Using DVMRP Routes Summary


The use of DVMRP for alternate path routing must be done using careful planning and configuration. Access-control lists must be used on all ip dvmrp metric commands if route loops and RPF problems are to be avoided. The administration problems can grow quite large for networks where DVMRP alternate path routing is used on a large scale basis. Furthermore, because the access-control lists used to control which unicast routes are injected into DVMRP are static, changes in topology can result in the network failing to route around failed links. The other alternative is to use a Ships-in-the-night approach where DVMRP routes are exchanged over every interface in the network! When this approach is used, only connected networks should be injected on every interface by every router in the network. (This is the default behavior if the ip dvmrp metric command is not used when ip dvmrp unicast-routing is enabled on an interface.) The advantage of this method is that no ACLs are necessary and the network will re-converge around failed links. The disadvantage is that the network is now running both DVMRP and a separate unicast routing protocol which pass each other like Ships-in-the-night at every point in the network. In most cases, this is generally not desirable.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

40

Alternate Path Routing

CONCLUSION
Multicast Alternate Path Routing is very complex to implement and administer.

Avoid doing it if you can!


Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

41 41

Alternate Path Routing Conclusion


The use of alternate path routing for multicast traffic generally results in complex and difficult to administer networks. Until new tools become available to simplify this task, Network administrators are advised to use this only as a last resort.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

41

Tunneling Capabilities

Tunnels are used when multicast routers dont have contiguous connectivity Support two types of encapsulations for IP multicast traffic
DVMRP tunnels (IP protocol number 4) GRE tunnel (IP protocol number 47)

Both are supported by fast switching

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

42 42

Tunneling Multicast
Cisco IOS supports two types of tunnels for IP Multicast traffic. Both of these tunnel modes are fast-switched. DVMRP Tunnels - This is actually an IP-in-IP tunnel and uses the protocol number of 4. DVMRP tunnels are not supported between two Cisco routers. It is solely intended for use between a Cisco router and a non-Cisco router running DVMRP. GRE Tunnels - IP Multicast traffic may be tunneled between two Cisco routers using GRE tunnels (protocol 47).

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

42

DVMRP Tunnels

Used between a Cisco router and a non-Cisco DVMRP router DVMRP Tunnel Example
interface tunnel0 tunnel source ethernet0 tunnel destination <ip-address> tunnel mode dvmrp ip unnumbered ethernet0 ip pim sparse-dense

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

43 43

DVMRP Tunnels
DVMRP tunnels are only used between Cisco routers and non-Cisco DVMRP routers. DVMRP tunnels cannot be used between two Cisco routers! A normal tunnel configuration (such as the one shown above) is used with the tunnel mode set to dvmrp.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

43

GRE Tunnels
Used between two Cisco routers Looks like a point-to-point link for all protocols in the box,
All packets get an extra IP header Provides data sequencing and security

Used when user wants non-congruent multicast and unicast topologies GRE Tunnel Example
interface tunnel0 tunnel source ethernet0 tunnel destination <ip-address> tunnel mode gre ip ip unnumbered ethernet0 ip pim sparse-dense
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

44 44

GRE Tunnels
When it is necessary to tunnel multicast traffic between two Cisco routers, a GRE Tunnel must be used. The GRE Tunnel appears as a point-to-point link to both ends. Each packet sent down the tunnel gets an extra IP header. GRE tunnels also provide data sequencing and some degree of security. A normal tunnel configuration (such as the one shown above) is used with the tunnel mode set to gre ip.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

44

Load Splitting using Tunnels


We use tunnels and load split across different (S,G) entries
Per packet when process level switching
(S1, G), oif = tu0 rewrite = serial0 (S2, G), oif = tu0 rewrite = serial1 tunnel0 serial0 serial1

When doing MAC level rewrite, select among a set of equal-cost paths to the tunnel endpoint
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

45 45

Load Splitting using Tunnels


Normally, a multicast traffic flow can have only one RPF interface. Even if multiple equal-cost routes exist in the unicast routing table, only the highest IP address is used. This normally precludes any load balancing of multicast traffic. However, the router can be made to see two equal-cost paths as a single interface if a Tunnel is used. The example above show how a tunnel may be used to accomplish a limited degree of load balancing. Tunnel0 is configured between the two routers. Multicast is enabled on Tunnel0 but not Serial0 and Serial1. Static Mroutes or some other form of alternate path routing is used so that the routers will RPF to Tunnel0 for all traffic arriving from the other router. (Warning: Care must be taken when alternate path routing is used to avoid route loops or black holes.) The load balancing method will depend on whether Tunnel0 is process or fastswitching. Fast Switching - Load balancing will be on a (*,G) or (S,G) flow basis. Process Switching - Load balancing will be on a per packet basis albeit at the reduced through-puts associated with Process Switching.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

45

SPT Thresholds

Shared trees are good for router state savings


When delay and frequency is not an issue

Source trees are good for low delay paths


At the expense of router state

SPT thresholds allow you to use both tree typesyou can tailor when you switch from shared to source trees
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

46 46

SPT Thresholds
The key advantage of a Shared Tree is that all multicast flows in the group may use the Shared Tree thereby reducing the amount of multicast forwarding state in the routers in the network. However, the (normally) sub-optimal paths of the Shared Tree introduce additional delay and possible points of congestion along the single common tree. Switching to Sources Trees (aka Shortest-Path Trees or SPT for short) is the default behavior of Ciscos PIM implementation. The advantage of Source Trees is that multicast flows via the shortest path from the sources to the receivers which reduces latency and the potential for congestion. However, this is accomplished at the expense of more multicast forwarding state in the routers in the network. SPT Thresholds permit the network engineer to tune at what point in terms of kbps a last-hop router switches to the SPT.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

46

SPT Thresholds

How to configure SPT-Thresholds


ip pim spt-threshold <kbps> | infinity [group-list <acl>]

Must be configured on all last-hop routers


Not in the RP

When you want only Shared Trees


ip pim spt-threshold infinity

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

47 47

SPT Thresholds
SPT Thresholds may be configured on a router using the global configuration command shown above. <kbps> | infinity Defines at what rate in kbps a last-hop router switches to the SPT. If the value of infinity is used the router will never switch to the SPT and traffic will only flow down the Shared Tree. Option ACL that defines the groups for which the SPT-threshold is applicable. If this ACL is not specified, all multicast groups are assumed.

group-list <acl> -

SPT-Thresholds must be configured on each individual router in the network. It will not have the desired affect if it is only configured on the RP. (This is because the RP does not communicate this value to the routers in the network.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

47

SPT Threshold Example

Forcing 224.2.0.0/16 traffic to remain on the Shared Tree


ip pim spt-threshold infinity group-list 1 access-list 1 permit 224.2.0.0 0.0.255.255

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

48 48

SPT-Threshold Example
In the above example, the network engineer desires to force all multicast traffic in the 224.2.0.0/16 group range to never switch to the SPT. This will help reduce the amount of multicast forwarding state in the network for this group at the expense of sub-optimal routing paths.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

48

IP Multicast Helper Maps

Problem: hosts take longer than routers to get IP multicast deployed Issue: there are host applications deployed that use UDP broadcast transmission Solution: have routers map broadcast address to multicast address
To make use of IP multicast in the infrastructure as soon as possible
49 49

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

IP Multicast Helper Maps


Although most of todays modern IP stacks support IGMP and multicast, there are still cases where multicast is not supported. For example, there are several cases where Tandem or IBM hosts are used to provide Stock Market ticker information that is sent via IP in unicast or (ugh) UDP broadcast. When it is desired to send this UDP broadcast traffic across a routed network, problems arise. UDP Flooding has often been used but is difficult to maintain and does not scale. The solution is to have the first-hop router convert the UDP Broadcast into multicast. This is a straight-forward process requiring the following steps: Packets of the UDP broadcast are identified by UDP port number. The destination broadcast IP address of the packet is rewritten with the desired multicast group address. A new checksum for the IP header is recalculated. The (now) multicast packet is forwarded as any other multicast packet. If it is also the case that the receivers do not support multicast, the last-hop routers can also convert specific multicast flows into local subnet broadcasts which can be received by these brain damaged hosts. This is also a straightforward process that requires the following steps: The router joins the desired multicast group. The packets desired UDP flow in this group are identified by UDP port number. The destination multicast group address is rewritten with the specified local subnet broadcast address. A new checksum for the IP header is recalculated. The (now) UDP broadcast packet is forwarded onto the local subnet.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module7.ppt 49

IP Multicast Helper Maps

Mapping from broadcast to multicast


ip multicast helper-map broadcast <group-addr> <acl> [ <ttl>]

Mapping from multicast to broadcast


ip multicast helper-map < group-addr> < bcast-address> < acl >

Router automatically joins group


ip igmp join-group < group-address >

The above command is automatically added to the router configuration

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

50 50

IP Multicast Helper Maps


Mapping from UDP Broadcast to Multicast is accomplished using the following command syntax: ip multicast helper-map broadcast <group-addr> <acl> <group-addr> - is the multicast group address that the router will use to replace the destination broadcast address in the received broadcast packet. <acl> - is an extended access-control list that is used to identify which UDP broadcast flow is to be converted to multicast. <ttl> - is an optional parameter that can be used to specify the TTL value of the multicast packet. This may be important if TTL Scoping is in use. Mapping from multicast back to broadcast is accomplished using the following command syntax: ip multicast helper-map <group-addr> <bcast-addr> <acl> <group-addr> - is the group address of the multicast flow that the router will convert back to a local broadcast. <bcast -addr> - is the destination broadcast address that the router will use to replace the above multicast group address when it rewrites the packet. (This address also identifies which interface/sub-net that the rewritten packet is to be sent.) <acl> - is an extended access-control list that is used to identify the UDP port number of the multicast flow that is to be converted to broadcast. When mapping from multicast back to broadcast, the router joins the group specified by the <group-addr> parameter by automatically adding an ip igmp join-group command to the configuration.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

50

IP Multicast Helper Maps


Broadcast Source .10 10.1.1.0/24

Broadcast to Multicast Conversion


.1 E0

Broadcast

Multicast A

ip multicast helper-map broadcast 224.1.1.1 100 ttl 15 ip forward-protocol udp 2000 access-list 100 permit any any udp 2000

ACL 100

multicast helper-map

Multicast Forwarding Engine

Broadcast
(10.1.1.10, 10.1.1.255) UDP Port 2000

any any udp 2000

Broadcast
(10.1.1.10, 10.1.1.255) UDP Port 2000

Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000

MATCH!
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

51 51

Broadcast to Multicast Conversion Details


In the top half of the above drawing, router A is configured to convert arriving UDP broadcast packets with a port number of 2000 into multicast packets with a destination group address of 224.1.1.1 and a TTL of 15. Extended access-list 100 is used to identify the UDP broadcast flow to UDP port 2000. (Note that it is necessary to configure the ip forward-protocol udp 2000 command to prevent the router from immediately discarding broadcast packets to UDP 2000.) The bottom half of the drawing show the steps that are taken by the router to convert the packet to multicast. A UDP broadcast packet with a UDP port of 2000 is received from host 10.1.1.10, sent to the subnet broadcast address 10.1.1.255. The packet is checked against extended access-list 100 to see if it matches the specified flow. (In this case, it does.) The matching packet is then sent to the multicast-helper front-end which simply replaces the destination broadcast address with the specified multicast group address (224.1.1.1) and recalculates a new IP header checksum. The (now) multicast packet is handed off to the routers Multicast Forwarding Engine which processes the packet like any other arriving multicast packet. (Note: As far as the Multicast Forwarding Engine is concerned, the packet was sent by the original host, in this case 10.1.1.10.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

51

IP Multicast Helper Maps


10.2.2.0/24

Multicast to Broadcast Conversion


Multicast
S0

Non-Multicast Receiver

.1 E0

Broadcast

ip multicast helper-map 224.1.1.1 10.2.2.255 100 ip forward-protocol udp 2000 access-list 100 permit any any udp 2000

Multicast Forwarding Engine

ACL 100

multicast helper-map

Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000

any any udp 2000

Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000

Broadcast
(10.1.1.10, 10.2.2.255) UDP Port 2000

MATCH!
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.

52 52

Multicast to Broadcast Conversion Details


In the top half of the above drawing, router A is configured to convert arriving group 224.1.1.1 multicast packets with a port number of 2000 into UDP broadcast packets with a destination subnet broadcast address of 10.2.2.255. Extended access-list 100 is used to identify UDP packets addressed to UDP port 2000 within the group 224.1.1.1 multicast flow. The bottom half of the drawing show the steps that are taken by the router to convert the packet to multicast. The Multicast Forwarding Engine identifies arriving multicast packets for group 224.1.1.1 and checks them against extended access-list 100 to see if it matches the specified flow. (In this case, it does.) The matching packet is then sent to the multicast-helper back-end which simply replaces the destination multicast group address (224.1.1.1) with the specified broadcast address (10.2.2.255) and recalculates a new IP header checksum. The (now) UDP broadcast packet is forwarded to the appropriate subnet. (Note that it is necessary to configure the ip forward-protocol udp 2000 command so the the router will forward the broadcast packets to the destination subnet.)

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

52

IP Multicast Helper Maps


Broadcast Source .10 10.1.1.0/24 10.2.2.0/24 Non-Multicast Receiver

.1 E0

S0

Multicast Capable Network

S0

.1 E0

ip multicast helper-map

Interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip directed-broadcasts ip multicast helper-map broadcast 224.1.1.1 100 ttl 15 access-list 100 permit any any udp 2000 ip forward-protocol udp 2000

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

53 53

IP Multicast Helper Maps - Example


This is an example configuration where the UDP broadcast traffic from a broadcast source is converted to IP Multicast, travels across the multicast enable network and is converted back to a directed subnet broadcast at the far end. The Router A configuration necessary to convert from broadcast to multicast is shown above. Notice the following: ip directed-broadcasts must be enabled. ip forward-protocol udp 2000 must be configured to prevent the router from ignoring the UDP broadcast packets. Extended access-list 100 is used to identify the UDP broadcast stream that is to be converted. The ip multicast helper-map command causes the UDP broadcast stream to be converted to a 224.1.1.1 multicast stream with a TTL of 15.

Copyright ? ?1998-2001, Cisco Systems, Inc.

Module7.ppt

53

IP Multicast Helper Maps


Broadcast Source .10 10.1.1.0/24 10.2.2.0/24 Non-Multicast Receiver

.1 E0

S0

Multicast Capable Network

S0

.1 E0

ip multicast helper-map Interface Serial0 ip address 172.16.255.2 255.255.255.252 ip multicast helper-map 224.1.1.1 10.2.2.255 100 ip igmp join-group 224.1.1.1 interface Ethernet0 ip address 10.2.2.1 255.255.255.0 ip directed-broadcast access-list 100 permit any any udp 2000 ip forward-protocol udp 2000

Module7. ppt

1998 2001, Cisco Systems, Inc. All rights reserved.

54 54

IP Multicast Helper Maps - Example


The Router B configuration necessa