IP Multicast Course

Citation preview

Course Presentation Material

Página 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

Página 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)

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

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

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.

1

Module1.ppt

1

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

Copyright ã 1999-2001, Cisco Systems, Inc.

2 2

Module1.ppt

2

Geekometer

Agenda

• 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

Copyright ã 1999-2001, Cisco Systems, Inc.

3 3

Module1.ppt

3

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

Copyright ã 1999-2001, Cisco Systems, Inc.

4 4

Module1.ppt

4

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

5

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

• Optimized Performance Performance: Eliminates traffic redundancy • Distributed Applications Applications: Makes multipoint applications possible Multicast Unicast 0.8

Example: Audio Streaming All clients listening to the same 8 Kbps audio

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

6

Multicast Disadvantages Multicast is UDP Based!!! • Best Effort Delivery: 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: 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 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

7

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

Training

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 Real--Time Data Delivery— Real Delivery—Financial n Module1. ppt

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

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

8

Example Multicast Applications Mbone Multicast Applications • sdr—session directory – Lists advertised sessions – Launches multicast application(s)

• vat—audio conferencing – PCM, DVI, GSM, and LPC4 compression

• vic—video conferencing – H.261 video compression

• wb—white 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

9

sdr—Session 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 creator’s 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

vat—Audio 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

vic—Video 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

wb—White 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 address—high-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.1—all multicast systems on subnet • 224.0.0.2—all 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 it’s forwarding decision, multicast forwarding uses the “source” address to make it’s 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

C

Receiver 1 Module1. ppt

F

E

Receiver 2

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

8/10/2001 3:45 PM

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

C

Receiver 1 Module1. ppt

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

D

F

E

Receiver 2 8/10/2001 3:45 PM

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

A

B

C

D (RP)

E

F

(RP)

PIM Rendezvous Point Shared Tree

Receiver 1 Module1. ppt

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

Receiver 2 8/10/2001 3:45 PM

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)

C

E

F

(RP)

PIM Rendezvous Point Shared Tree Source Tree

Receiver 1 Module1. ppt

Receiver 2

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

8/10/2001 3:45 PM

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 OSPF’s 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 RPF…this 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

RPF Checks Fail Packets arrived on wrong interface!

Mcast Dist. Tree Mcast Packets

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 X

Multicast Packet from Source 151.10.3.21

S0

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

Module1. ppt

S1

S2 E0

Packet Arrived on Wrong Interface! Discard Packet!

©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

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

Module1. ppt

S2 E0

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

©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 TTL -Threshold (16). FORWARD E0: TTL (23) > TTL -Threshold (0).

FORWARD

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

Copyright ã 1999-2001, Cisco Systems, Inc.

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 ’ 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

Copyright ã 1999-2001, Cisco Systems, Inc.

39 39

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 TBT’s • 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 • 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)

Source Network “S1”

A

B

mrouted 1

mrouted

mrouted

33

1 33

1 mrouted

C

X 3 2 mrouted

mrouted 2

D

35

34

E

35 3

Y mrouted

2 n

Route for source network of metric “n”

m

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

Module1. ppt

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

8/10/2001 3:45 PM

41 41

• 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 TBT’s 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” • Both B & C have routes to network S1.

A

• To avoid duplicates, only one router can be “Designated Forwarder” for network S1.

mrouted 1

1

mrouted

B

mrouted 2

C

• Router with best metric is elected as the “Designated Forwarder”. • Lowest IP address used as tie-breaker. • Router C wins in this example.

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 network’s 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

B

mrouted

mrouted

X mrouted

mrouted

C

mrouted

D

mrouted

E

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

A

B

mrouted

Each Source Network has it’s Own Truncated Broadcast Tree

mrouted

X mrouted

mrouted

C

mrouted

D

mrouted

E

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 TBT’s 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 TBT’s – The advantage of TBT’s 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 TBT’s – The disadvantage of using TBT’s 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”

A mrouted

B

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

mrouted

X mrouted

mrouted

C

mrouted

D

mrouted

E

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”

A mrouted

B

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

mrouted

X mrouted

Prune

mrouted

C

mrouted

D

mrouted

E

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

A mrouted

Source “S”

Routers X, and Y are also Leaf Nodes so they send “Prune (S, G)” Messages

B

Router E prunes interface. Prune

mrouted

X

mrouted

mrouted

C

mrouted

D

mrouted

E

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”

A mrouted

B

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

mrouted

X mrouted Prune

mrouted

C

mrouted

D

mrouted

E

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 E’s 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

Final Pruned State

mrouted

X mrouted

mrouted

C

mrouted

D

mrouted

E

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 Convergence—RIP-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 LSA’s 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 LSA’s Area 0

MABR1

MABR2

Area 1

Area 2

Membership LSA’s

MA Module1. ppt

Membership LSA’s

MB

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 LSA’s announcing the existence of these members on their networks. These LSA’s are flooded throughout the area. – Notice that these Group Membership LSA’s 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

MABR1

MABR2

Area 1

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 LSA’s 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 Area 0

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

Wildcard Receiver Flag

(*, *)

(*, *)

MABR1

MABR2

Area 1

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 LSA’s 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

MABR2

Area 1

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 LSA’s 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)

(GA )

Summarized Membership LSA

Summarized Membership LSA

MABR1

MABR2

Area 1

Area 2

Membership LSA’s

MA Module1. ppt

Membership LSA’s

MB

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 LSA’s – In addition to Group Membership LSA’s MOSPF also defines a new Summary Membership LSA that is used to summarise an area’s group membership information. – Summary Membership LSA’s 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 LSA’s in their Dijkstra calculations to know which MABR’s 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

MABR2

Area 1

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 LSA’s 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

MABR2

Area 1

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 MABR’s 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 MASBR

Area 0 Summarized Membership LSA

External AS Summarized Membership LSA

(GA , GB)

MABR1

(GA )

MABR2

Area 1

Area 2

Membership LSA’s

MA Module1. ppt

Membership LSA’s

MB

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 LSA’s inform the routers in the backbone of which MABR’s has members of which groups.

Copyright ã 1999-2001, Cisco Systems, Inc.

Module1.ppt

59

MOSPF Inter-Domain Traffic MASBR

Area 0

MABR1

External AS (S1 , A) (S2 , B)

MABR2

Area 1

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 MABR’s as necessary based on the Summary Membership LSA’s 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 MASBR

Area 0

External AS

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

Wildcard Receiver Flag

(*, *)

(*, *)

MABR1

MABR2

Area 1

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.) – MASBR’s 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 dependent—works 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

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

Multicast Packets

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

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

Multicast Packets

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

S0

2

Assert

E0

1

2 Assert

E0

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 let’s assume that the forwarding interface of the first-hop router fails as shown above. – Let’s 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 hasn’t 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 it’s 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 – Let’s 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 configure—two 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

Copyright ã 1999-2001, Cisco Systems, Inc.

76 76

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) State created only along the Shared Tree.

(*, G) Joins Shared Tree Receiver

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

RP

Source

(S, G) Register

(unicast)

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

(S, G) Joins Shared Tree 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

RP

Source

(S, G) Register

(unicast)

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

(unicast)

Module1. ppt

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

Receiver

©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 source’s 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

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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

RP

Source

Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes

Module1. ppt

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.

©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

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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

RP

Source

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

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

Module1.ppt

Receiver

©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

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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 receivers (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.

Copyright ã 1999-2001, Cisco Systems, Inc.

91

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.

1

Module2.ppt

1

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

Copyright ? ?1998-2001 Cisco Systems, Inc.

2 2

Module2.ppt

2

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

Copyright ? ?1998-2001 Cisco Systems, Inc.

3 3

Module2.ppt

3

3

Layer 3 Multicast Addressing • IP group addresses 224.0.0.0–239.255.255.255 • “Class D” addresses = high order bits of “1110” • Special reserved group addresses: 224.0.0.0–224.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

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

8/9/2001 4:20 PM

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

(RFC1583)

224.0.0.6 - OSPF DESIGNATED ROUTERS

(RFC1583)

224.0.0.9 - RIP2 Routers 224.0.0.13 - PIMv2 224.0.1.39 - CISCO-RP-ANNOUNCE

(Auto-RP)

224.0.1.40 - CISCO-RP-DISCOVERY

(Auto-RP)

“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

4

Layer 2 Multicast Addressing IP Multicast MAC Address Mapping (FDDI and Ethernet) 32 Bits 28 Bits

1110

239.255.0.1 5 Bits Lost

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

23 Bits 48 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 OUI’s 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. (It’s too bad that it wasn’t 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 OUI’s. :-) ) Copyright ? ?1998-2001 Cisco Systems, Inc.

Module2.ppt

5

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

1 - Multicast MAC Address (FDDI and Ethernet)

0x0100.5E01.0101

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

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

6

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

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

(Shown in Token Ring, non-canonical format)

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

7

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

8

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

9

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 vendors.

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 60–120 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

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

8/9/2001 4:20 PM

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

IGMPv1—Packet Format 4 Ver

7 Type

15 Unused

23

31

Checksum

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

IGMPv1—Joining a Group H2

H1

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

IGMPv1—General Queries H2

H1

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

IGMPv1—Maintaining a Group 224.1.1.1

H1

224.1.1.1

H2

X

224.1.1.1

H3

X

Suppressed #3

Report #2

Suppressed #3 Query to 224.0.0.1

#1

IGMPv1 #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, H2’s 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

IGMPv1—Leaving a Group H2

H1

H3

Query to 224.0.0.1 IGMPv1

• Router sends periodic queries • Hosts silently leave group • Router continues sending periodic queries • No Reports for group received by router • Group times out

Module2. ppt

©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)

Module2. ppt

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

8/9/2001 4:20 PM

17 17

• 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

IGMPv2—Packet Format 7 Type

15 Max. Resp. Time

31 Checksum

Group Address

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

IGMPv2—Joining a Group 1.1.1.10 H1

1.1.1.11 224.1.1.1

1.1.1.12

H2

H3

Report 1.1.1.1 rtr-a

• Joining member sends report to 224.1.1.1 immediately upon joining (same as IGMPv1) Module2. ppt

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

8/9/2001 4:20 PM

20 20

• 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

IGMPv2—Joining a Group 1.1.1.10

1.1.1.11

1.1.1.12

H1

H2

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

Module2. ppt

Expires 00:02:31

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

Last Reporter 1.1.1.11

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

IGMPv2—Querier Election 1.1.1.10

1.1.1.11

1.1.1.12

H1

H2

H3

Query

1.1.1.2

IGMP Non-Querier

Query

1.1.1.1

IGMP Querier

IGMPv2 rtr-b

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 Group’s 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

IGMPv2—Querier 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

IGMPv2—Maintaining a Group 1.1.1.10 224.1.1.1

X

H1

Suppressed

1.1.1.11 224.1.1.1

1.1.1.12 224.1.1.1

H2

X

H3

Suppressed

Report

1.1.1.1

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, H2’s 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

IGMPv2—Leaving a Group 1.1.1.10

1.1.1.11

1.1.1.12

H1

H2

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

Module2. ppt

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

Expires 00:02:31

Last Reporter 1.1.1.11

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

IGMPv2—Leaving a Group 1.1.1.10 H1

1.1.1.11 224.1.1.1 Leave to #1 224.0.0.2

1.1.1.12 224.1.1.1

H2

Report to #3 224.1.1.1 1.1.1.1 rtr-a

• • • •

H3

Group Specific Query to 224.1.1.1 #2

H2 leaves group; sends Leave message Router sends Group specific query A remaining member host sends report Group remains active

Module2. ppt

©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 hasn’t 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

IGMPv2—Leaving a Group 1.1.1.10

1.1.1.11

1.1.1.12

H1

H2

H3

1.1.1.1 rtr-a

IGMP State in “rtr-a” after H2 Leaves rtr-a>sh rtr-a>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

Module2. ppt

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

Expires Last Expires Last Reporter Reporter 00:01:47 00:01:47 1.1.1.12 1.1.1.12

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

IGMPv2—Leaving a Group 1.1.1.10 H1

1.1.1.11 H2

1.1.1.12 224.1.1.1

H3

Leave to #1 224.0.0.2 1.1.1.1 rtr-a

• • • •

Group Specific Query to 224.1.1.1 #2

Last host leaves group; sends Leave message Router sends Group specific query No report is received Group times out

Module2. ppt

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

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

IGMPv2—Leaving a Group 1.1.1.10

1.1.1.11

1.1.1.12

H1

H2

H3

1.1.1.1 rtr-a

IGMP State in “rtr-a” after H3 Leaves rtr-a>show rtr-a>show ip ip igmp igmp group group IGMP IGMP Connected Connected Group Group Membership Membership Group Interface Uptime Group Address Address Interface Uptime

Module2. ppt

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

Expires Expires

Last Last Reporter Reporter

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

IGMPv2—Response 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

IGMPv2—Response Tuning Query

Query

Query Resp. Interval

Query

Query Resp. Interval

Query Interval

Query

Query Resp. Interval

Query Interval

Query

Query Resp. Interval Query Interval

Query

Query Resp. Interval

Query Resp. Interval

Query 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

IGMPv2—Response Tuning

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

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

Module2. ppt

Tuning the Query Response Interval (Default = 10 secs)

Tuning the Query Interval (Default = 60 secs)

©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

IGMPv2—Response 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

H2

H3

IGMPv1 Report #2 1.1.1.1

IGMPv1 #1 Query

IGMPv1 Host H2: • MUST always send IGMPv1 Reports • MAY suppress IGMPv2 Leaves

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

IGMPv2

H2

H3

224.1.1.1 Report 1.1.1.1 IGMPv2

Router A

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.

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 H2

H1

1.1.1.1 IGMPv2

H3

1.1.1.2 IGMPv1

Router A

Router B

Router A: • 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 )

7 Type = 0x11

Group Address: Multicast Group Address (0.0.0.0 for General Queries)

15 Max. Resp. Code Group Address

S QRV

QQIC

Number of Sources (N)

Source Address [1] Source Address [2]

S Flag Suppresses processing by routers QRV (Querier Robustness Value) Affects timers and # of retries

31 Checksum

. . . Source Address [N]

QQIC (Querier’s 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.

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)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

Module3. ppt

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

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

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

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

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

26 26

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 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 doesn’t 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

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

32 32

Module3.ppt

32

PIM DM Flooding S1

S0 S3

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 S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

Arriving data causes ‘rtr-a’ to create state

rtr-a

S3 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: 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: 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: TT 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 S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

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

S3

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: 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: 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: TT 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 S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

Arriving data causes ‘rtr-b’ to create state

S3

rtr-a

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: 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: 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 let’s assume that the forwarding interface of the first-hop router fails as shown above. • Let’s 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 hasn’t 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

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

40 40

Module3.ppt

40

PIM DM Pruning S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

Initial “Flooding” State in “rtr-a”

S3

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: 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: 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: TT 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 S1

S0

rtr-a

S3

X

Multicast Packets (128.9.160.43, 224.2.127.254) 2 Prune

3

S0

rtr-b E1

1

“rtr-a” initially floods (S, G) traffic out all interfaces in “oilist”.

2

“rtr-b” is a leaf node w/o receivers. Sends Prune for (S,G).

3

“rtr-a” Prunes interface for (S,G).

Module3. ppt

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

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-b’s (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 S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

State in “rtr-a” after Pruning

S3

rtr-a

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: 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: 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: TT 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 S1

S0 Multicast Packets (128.9.160.43, 224.2.127.254)

State in ‘rtr-b’ before/after Pruning

S3

rtr-a

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: 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: 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

S1

S0

I’ll wait 3 secs to see 2 if someone else wants (S,G) before I Prune Interface E0.

(S,G) Packets E0 1

Prune

4

E0

E0

rtr-b

Join 3

rtr-c

E1

E1

Receiver

1

“rtr-b” is a leaf node w/o receivers. Sends Prune for (S,G).

2

“rtr-a” schedules a Prune for (S,G) to occur in 3 seconds.

3

“rtr-c” hears Prune from “rtr-b”. Overrides with a Join.

4

“rtr-a” hears Join and cancels Prune for (S,G).

Module3. ppt

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

8/10/2001 11:41 AM

45 45

• PIM Prune Delay on Multi-access Networks • rtr-a schedules a prune when asked but doesn’t 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!!! X

Source

X

X

X

Prune 3 sec delay

3 sec delay

Prune

Prune 3 sec delay

Prune 3 sec delay

• 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

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

47 47

Module3.ppt

47

PIM DM Grafting S0 S1

(S,G) Packets

E0

rtr-a

E0

E0

rtr-b

rtr-c

E1

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, we’ll assume hasn’t been pruned.

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

Module3.ppt

48

PIM DM Grafting S0 S1

(S,G) Packets

E0

rtr-a

E0

Beginning State in “rtr-a”

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: 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: 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: TT 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 S1

(S,G) Packets

E0

rtr-a

E0

E0

rtr-b

rtr-c

E1

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: 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: 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 S1

(S,G) Packets

E0

rtr-a

E0

E0

rtr-b

rtr-c

E1

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: 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: 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 S1

(S,G) Packets 3 PIM Graft-ACK

E0

rtr-a

4

E0 2 PIM Graft

E0

rtr-b

rtr-c

E1

E1 IGMP Join

Rcvr A

1

1•

“Rcvr A” wishes to receive group G traffic. Sends IGMP Join for G.

2 •

“rtr-b” sends PIM Graft for Group (S,G).

3 •

“rtr-a” acknowledges with a PIM Graft-Ack.

4 •

“rtr-a” begins forwarding traffic for (S,G).

Module3. ppt

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

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 S1

(S,G) Packets

E0

rtr-a

E0

State in “rtr-a” after Grafting

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: 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: 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: TT 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 S1

(S,G) Packets

E0

rtr-a

E0

E0

rtr-b

rtr-c

E1

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: 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: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet1, Forward/Dense, Ethernet1, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, T (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: CCT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing Outgoing interface interface list: 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 S1

(S,G) Packets

E0

rtr-a

E0

E0

rtr-b

rtr-c

E1

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: 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: 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

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

56 56

Module3.ppt

56

PIM Assert Mechanism Incoming Multicast Packet (Successful RPF Check)

S0 A E0 .1

S0 B 1

E0 .2

C

Receiver

192.168.1.0/24

1

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

Winner S0

2

S0 B

Pruned

E0 .2

X

Assert

A E0 .1

2 Assert

192.168.1.0/24

C 2

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

Winner S0

S0

A E0 .1

B Prune

X

E0 .2

192.168.1.0/24

3

Join 4

C

Receiver

3

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.

4

Router C does need traffic. Sends join to override.

Module3. ppt

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

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

Winner S0

S0

A E0 .1

B Pruned 6

X

X

E0 .2

192.168.1.0/24 5 C 5

If router C doesn’t need the traffic, no Join override is sent.

6

Router B prunes its interface after 3 second prune delay. – This stops the flow of traffic onto the transit LAN.

Module3. ppt

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

8/10/2001 11:41 AM

60 60

• 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 B’s 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 S0

A .1

S0

E0

B E0

.2 198.92.2.0/24

Routing Protocol Boundary

State in Router C before Assert

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

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 C’s 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

S0

A .1

S0

E0

Assert Loser

B E0

.2

Assert

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

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

S0

A .1

S0

E0

Assert Loser

B E0

.2

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

S0

A .1

S0

E0

Assert Loser

B E0

.2 198.92.2.0/24

Routing Protocol Boundary

State in Router C after Assert

C

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 didn’t 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 it’s 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 • Let’s 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

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

69 69

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

Module3. ppt

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

I Receiver 2

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

I

Receiver 1

Module3. ppt

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

Receiver 2

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

B G

Prune C

D

F H

E

I

Receiver 1

Module3. ppt

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

Receiver 2

8/10/2001 11:41 AM

73 73

• PIM Dense Mode Review (cont.) • The link between B & C is not C’s 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

D

F

Asserts H E

I

Receiver 1

Module3. ppt

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

Receiver 2

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

A

B G

C

D

F H

Prune E

I

Receiver 1

Module3. ppt

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

Receiver 2

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 E’s Prune is Ignored

A

B G

C

D

F H

Prune E

I

Receiver 1

Module3. ppt

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

Receiver 2

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

G’s Prune is Overridden A

Prune

B

G C

D

F

Join Override H

E

I

Receiver 1

Module3. ppt

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

Receiver 2

8/10/2001 11:41 AM

77 77

• PIM Dense Mode Review (cont.) • G prunes since it doesn’t 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

A

B G

C

D

F H

Graft E

I

Receiver 1

Receiver 2 Receiver 3

Module3. ppt

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

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

A

B G

C

D

F H

E

I

Receiver 1

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.

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

81

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.

1

Module4.ppt

1

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.

2

Module4.ppt

2

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.

3

Module4.ppt

3

3

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.

4

Module4.ppt

4

3

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

Module4. ppt

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

Uptime Uptime 3d16h 3d16h 4d15h 4d15h

Expires Expires Last Last RReporter eporter 00:01:59 00:01:59 172.16 172.16.7.2 .7.2 never 172.16 .6.2 never 172.16 .6.2

8/10/2001 1:55 PM

5

• 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

5

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

6

• 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

6

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

Module4. ppt

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

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

8/10/2001 1:55 PM

7

• 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

7

show ip pim interface

R6#show R6#show ip ip pim pim interface interface Address Interface Address Interface

Mode Mode

172.16.10.1 172.16.10.1 172.16.11.1 172.16.11.1 172.16.9.2 172.16.9.2

Dense Dense Dense Dense Dense Dense

Module4. ppt

Serial0 Serial0 Serial1 Serial1 Ethernet0 Ethernet0

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

Nbr DR Nbr Query Query DR Count Count Intvl Intvl 11 30 0. 30 0.0.0.0 0.0.0 11 30 0. 30 0.0.0.0 0.0.0 11 30 17 30 172.16.9.2 2.16.9.2

8/10/2001 1:55 PM

8

• 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

8

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

9

• 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

9

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

Module4. ppt

172.16.0.0/24 172.16.0.0/24 is is subnetted subnetted,, 77 subnets 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 172.16.10.0 [90/2281542] [90/2281542] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet Ethernet00 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 192.169.1.0 [90/2349056] [90/2349056] via via 172.16.6.1, 172.16.6.1, 3d15h, 3d15h, Ethernet Ethernet00

©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 barrnet-gw>show -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 Cisco’s 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 barrnet-gw>show -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: Source: 192.36.125.68 192.36.125.68 (falcon. (falcon.pilsnet pilsnet.sunet.se) .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: Source: 146.139.72.5 146.139.72.5 (aem005.amc (aem005.amc.anl.gov .anl.gov)) Rate: Rate: 11 pps pps/5 /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 Forwarding Counts: Pkt Count/Pkts per second/ second/Avg Avg Pkt Pkt Size/Kilobits Size/Kilobits per per second second Other Other counts: counts: Total/RPF Total/RPF failed/Other failed/Other drops(OIF-null, drops(OIF-null, rate rate-limit -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: 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/123/113 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 PIM Group Group-to-RP -to-RP Mappings Mappings This system is an RP (Auto This system is an RP (Auto-RP) -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 RP 171.69.10.13 171.69.10.13 ((sj-mbone-loopback0. sj-mbone-loopback0.cisco cisco.com), .com), v2v1 v2v1 Info Info source: source: 171.69.10.13 171.69.10.13 ((sj-mbone-loopback0. sj-mbone-loopback0.cisco cisco.com), .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 RP 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1.cisco.com), cisco.com), v2v1 v2v1 Info Info source: source: 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1.cisco.com), 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. (RP’s 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 ” 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

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

17 17

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 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: Attribute: rtpmap rtpmap:96 :96 WBIH/90000 WBIH/90000 Media: 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 1033 Media Media group: group: 224.2.220.101, 224.2.220.101, ttl: ttl: 15 15 Attribute: Attribute: rtpmap rtpmap:96 :96 L8/22050/2 L8/22050/2 Attribute: Attribute: rtpmap rtpmap:97 :97 L8/22050 L8/22050 Attribute: Attribute: rtpmap rtpmap:98 :98 L8/11025/2 L8/11025/2 ... ... Module4. ppt

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

8/10/2001 1:55 PM

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

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

19 19

Module4.ppt

19

3

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: 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 .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: 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 .40 IGMP: Received v2 Report from 172.16.6.1 IGMP: Received v2 Report from 172.16.6.1 (Ethernet0) (Ethernet0) for for 224.0.1 224.0.1.40 .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: PIM: Send Send Router Router-Query -Query on on Ethernet0 Ethernet0 PIM: PIM: Send Send Router Router-Query -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: PIM: Join Join-list: -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 -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: 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.11 PIM: PIM: Received Received RP RP-Reachable -Reachable on on Serial1 Serial1 from from 172.16.8.1 172.16.8.1 PIM: PIM: Received Received RP RP-Reachable -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: PIM: Join Join-list: -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, PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Fo Forward 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: PIM: Join Join-list: -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: 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 Forward 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, PIM: Send Join on Ethernet1 to 172.16.8.2 for (172.16.12.2/32, 2224.1.1.1) 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: 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 Forward 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: PIM: Join Join-list: -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 -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: 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 -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

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

28 28

Module4.ppt

28

3

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

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

29 29

Module4.ppt

29

mtrace/mstat—How it works

Mtrace Packet Flow Adds mtrace data

Adds mtrace data

Adds mtrace data

Adds mtrace data

Adds mtrace data

src

dest

First-hop Router

mt rac e

res po ns e

e rac mt

Multicast Dist. Tree

st ue req

Last-hop Router

Mtrace Packet

Note: Mtracepackets use special IGMP packets with IGMP Type codes of 0x1E and 0x1F. Module4. ppt

Unix Workstation or Cisco Router

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

8/10/2001 1:55 PM

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

30 30

Module4.ppt

30

mtrace/mstat—How it works • Uses a special IGMP packet type – IGMP type 0x1F =

Queries/Requests

– IGMP type 0x1E =

Response

• Requestor sends Query/Request packet – Sent to last-hop router of destination – Can be initiated by 3rd Party

• Last-hop router rcv’s 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

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

31 31

Module4.ppt

31

mtrace/mstat—How 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

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

8/10/2001 1:55 PM

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

32 32

Module4.ppt

32

mtrace/mstat—How 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

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

33 33

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

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

34 34

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... 00 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^ 00 33 ms ms -2 -2 wan-gw4 wan-gw4 (171.68.86.193) (171.68.86.193) PIM PIM thresh^ thresh^ 00 32 32 ms ms -3 -3 bloomington-mn-gw bloomington-mn-gw (171.68.27.2) (171.68.27.2) PIM PIM thresh^ thresh^ 00 717 717 ms ms -4 -4 bloom-mnlab bloom-mnlab (171.68.39.28) (171.68.39.28) PIM PIM thresh^ thresh^ 00 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

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

36 36

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 vv // hop --------------------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 00 ttl vv || hop -11/168 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 11 ttl vv || hop -9/170 17 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 22 ttl vv || hop ms -3/195 19 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 33 \__ ttl vv \\ hop ms 196 19 hop 00 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%

66 pps pps

-3/67 -3/67 == --% --%

66 pps pps

0/70 0/70 == 0% 0%

77 pps pps

70 70

8/10/2001 1:55 PM

77 pps pps

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 vv // hop --------------------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 00 ttl vv || hop 77/694 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 11 ttl vv || hop 395/609 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 22 ttl vv || hop ms -8/39 33 pps hop 30 30 ms -8/39 == --% --% pps 171.68.86.194 171.68.86.194 171.68.37.1 dallas-gw 171.68.37.1 dallas-gw || \__ ttl 33 \__ ttl vv \\ hop ms 39 33 pps hop 00 ms 39 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%

66 pps pps

44/65 44/65 == 68% 68%

66 pps pps

-1/21 -1/21 == --% --%

22 pps pps

22 22

8/10/2001 1:55 PM

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

22 pps pps

38 38

Module4.ppt

38

mrinfo

berwyn-gw>mrinfo berwyn-gw>mrinfo berwyn berwyn-gw -gw 171.68.56.1 171.68.56.1 (berwyn (berwyn-gw.cisco.com) -gw.cisco.com) [version [version cisco cisco 11.2] 11.2] [flags: [flags: PMSA]: PMSA]: 171.68.56.97 171.68.56.97 -> -> 0.0.0.0 0.0.0.0 [1/0/pim/ [1/0/pim/querier/leaf] 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 Sending 1, 1, 100 100-byte -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 [detail]

Module4. ppt

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

8/10/2001 1:55 PM

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

41 41

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

Module4. ppt

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

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

8/10/2001 1:55 PM

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

42 42

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

Network

Receivers

Signaling

NA

?

?

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 doesn’t, then it probably isn’t. 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

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

46 46

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

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

47 47

Module4.ppt

47

PIM Sparse mode troubleshooting

• show ip pim rp [] – 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

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

48 48

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 rec’d only – pruning - watch pruning and grafting only Module4. ppt

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

8/10/2001 1:55 PM

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

49 49

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

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

50 50

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

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

51 51

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

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

52 52

Module4.ppt

52

Module4. ppt

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

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

53

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.

1

Module5.ppt

1

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

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

2 2

Module5.ppt

2

Geekometer

Module Agenda

• 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

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

3 3

Module5.ppt

3

3

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

4

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 RP’s for a range(s) group(s). This is accomplished via access-lists. This permits the RP’s 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 – RP’s 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 RP’s.

• 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

5

PIM-SM Shared Tree Joins

RP

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

(*, G) Joins Shared Tree Receiver

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

6

PIM-SM Sender Registration

RP

Source

(S, G) Register

(unicast)

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

(S, G) Joins Shared Tree 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

7

PIM-SM Sender Registration

RP

Source

(S, G) Register

(unicast)

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

(unicast)

Module5. ppt

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

Receiver

©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 source’s first hop router to inform it that it can stop sending the unicast Register messages.

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

Module5.ppt

8

PIM-SM Sender Registration

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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

9

PIM-SM SPT Switchover

RP

Source

Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes

Module5. ppt

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.

©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

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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

RP

Source

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

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

Module5.ppt

Receiver

©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

RP

Source

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

Traffic Flow Shared Tree Source Tree Receiver

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

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

14 14

Module5.ppt

14

PIM Neighbor Discovery Highest IP Address elected as “DR” (Designated Router)

171.68.37.2 PIM Router 2

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

Module5. ppt

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

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

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

16 16

8/10/2001 2:37 PM

• “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

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

17 17

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,

Module5. ppt

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

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

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 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 doesn’t 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) OIL’s. (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 interface’s 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) OIL’s.

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

– In (*, G) entry • Indicates SPT-Threshold is being exceeded • Next (S,G) received will trigger join of SPT

– 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 Module5. ppt

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

8/10/2001 2:37 PM

26 26

• 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 RP’s 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

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

29 29

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 Neighbor’s 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 S1

To RP (10.1.5.1)

rtr-a

S0

10.1.4.2 Shared Tree 10.1.2.2

1 IGMP Join

E1

E0

10.1.2.1

E0

rtr-b

Rcvr A

1•

“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 S1

To RP (10.1.5.1)

rtr-a

S0

10.1.4.2 Shared Tree 10.1.2.2

E1

E0

10.1.2.1

E0

rtr-b

Rcvr A

(*, (*, 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 neighbor’s 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; it’s 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 S1

To RP (10.1.5.1)

rtr-a

S0

10.1.4.2

E0

Shared Tree 10.1.2.2

E0

10.1.2.1

2 PIM Join

E1

rtr-b

Rcvr A

1•

“Rcvr A” wishes to receive group G traffic. Sends IGMP Join for G.

2 •

“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-b’s 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 S1

To RP (10.1.5.1)

rtr-a

S0

10.1.4.2 Shared Tree 10.1.2.2

E1

E0

10.1.2.1

E0

rtr-b

Rcvr A

(*, (*, 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: SS 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 neighbor’s 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; it’s 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

3 PIM Join

S1

rtr-a

S0

10.1.4.2

Shared Tree 10.1.2.2

E0

10.1.2.1

E0

E1

rtr-b

Rcvr A

1•

“Rcvr A” wishes to receive group G traffic. Sends IGMP Join for G.

2 •

“rtr-b” sends (*,G) Join towards RP.

3 •

“rtr-a” sends (*,G) Join towards RP.

4 •

Shared tree is built all the way back to the RP.

Module5. ppt

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

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-a’s 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

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

36 36

Module5.ppt

36

PIM SM Registering • Senders begin sourcing Multicast Traffic – Senders don’t 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 it’s 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) entry’s “oilist”. • If it hasn’t 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

rtr-a

S0

S1

rtr-b

S3 S0

S1

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.

40 40

8/10/2001 2:37 PM

• State in RP before Registering (Rcvr’s 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

rtr-a

S0

S1

rtr-b

S3 S0

S1

rtr-c

Shared Tree

rtr-b>sh rtr-b>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

rtr-a

S0

S1

rtr-b

S3 S0

S1

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 RP

1 Source 171.68.37.121

E0

S0

rtr-a

S0

S1

rtr-b

S3 S0

S1

rtr-c

Shared Tree

1•

“Source” begins sending group G traffic.

Module5. ppt

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

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 2

(171.68.37.121, 224.1.1.1) Mcast Packets

Register Msgs RP

Source 171.68.37.121

E0

S0

rtr-a

S0

S1

S3

rtr-b

S0

S1

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 (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: FPT 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.

Module5. ppt

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

44 44

8/10/2001 2:37 PM

• 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

Source 171.68.37.121

E0

Register Msgs 171.68.28.139 S0

rtr-a

S0

S1

rtr-b

RP S3 S0

S1

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.

Module5. ppt

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

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

Source 171.68.37.121

E0

Register Msgs (S,G) Join

S0

rtr-a

S0

4 S0

RP

S1

rtr-b

S0

S1

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree

4 •

RP sends (S,G) Join toward Source to build SPT.

Module5. ppt

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

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

Register Msgs (S,G) Join

Source 171.68.37.121

E0

S0

5 S0

RP

S0

rtr-a

S1 S0

rtr-b

S1

rtr-c (*, 224.1.1.1) Mcast Traffic

171.68.28.190 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.

Module5. ppt

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

47 47

8/10/2001 2:37 PM

• “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-a’s 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

rtr-a

S1

rtr-b

S0

S1

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

RP

S0

S0

rtr-a

S1

rtr-b

7 Register -Stop

6•

RP begins receiving (S,G) traffic down SPT.

7 •

RP sends “Register-Stop” to “rtr-a”.

Module5. ppt

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

S0

S1

rtr-c (*, 224.1.1.1) Mcast Traffic

Shared Tree

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

rtr-a

RP S0

S1

rtr-b

S3 S0

S1

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.

Module5. ppt

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

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

rtr-a

S1

rtr-b

S0

S1

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: TT 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

rtr-a

S0

S1

rtr-b

S3 S0

S1

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

rtr-a

S1

rtr-b

S3 S0

S1

rtr-c

rtr-c>show rtr-c>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.

54 54

8/10/2001 2:37 PM

• State in RP before Registering (w/o Rcvr’s 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

rtr-a

S0

S1

rtr-b

S3 S0

S1

rtr-c

rtr-b>show rtr-b>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

rtr-a

S0

S1

rtr-b

S3 S0

S1

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 RP

1 Source 171.68.37.121

1•

E0

S0

S0

rtr-a

S1

rtr-b

S3 S0

S1

rtr-c

“Source” begins sending group G traffic.

Module5. ppt

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

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 OIL’s 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 2 Register Msgs

(171.68.37.121, 224.1.1.1) Mcast Packets

RP Source 171.68.37.121

E0

S0

rtr-a

S0

S1

S3

rtr-b

S0

S1

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 (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: FPT 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.

Module5. ppt

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

58 58

8/10/2001 2:37 PM

• 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

Source 171.68.37.121

E0

Register Msgs 171.68.28.139 S0

rtr-a

S0

S1

RP

3

S3

rtr-b

S0

S1

rtr-c

(*, 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

rtr-a

S1

Register -Stop

4 •

S3 S0

rtr-b

S1

rtr-c

4

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

5 •

E0

rtr-a

S0

S0

5

S1

rtr-b

S3 S0

S1

rtr-c

“rtr-a” stops encapsulating traffic in Register Messages; drops packets from Source.

Module5. ppt

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

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

rtr-a

S0

S1

S3

rtr-b

S0

S1

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 Rcvr’s 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

rtr-a

S0

S1

rtr-b

S3 S0

S1

rtr-c

rtr-b>show rtr-b>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 Rcvr’s 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

rtr-a

S0

S1

S3

rtr-b

S0

S1

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: PP 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 Rcvr’s 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

rtr-a

S1

rtr-b

S3 S0

S1

(*, G) Join

rtr-c

6

Receivers begin joining the Shared Tree

6•

RP (“rtr-c”) receives (*, G) Join from a receiver on Shared Tree.

Module5. ppt

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

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

Source 171.68.37.121

E0

S0

rtr-a

S0

S1

RP

S3

rtr-b

S0

S1

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.

Module5. ppt

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

66 66

8/10/2001 2:37 PM

• 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 OIL’s of all (S,G) entries are always kept in sync with their parent (*, G). Note: When the (S, G) OIL’s 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

Source 171.68.37.121

E0

S0

RP

S0

rtr-a

S1

S3

rtr-b

S0

S1

rtr-c

171.68.28.190

(*, (*, 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.

Module5. ppt

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

67 67

8/10/2001 2:37 PM

• “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-a’s 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

rtr-a

RP S0

S1

rtr-b

S3 S0

S1

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

rtr-a

S1

rtr-b

S3 S0

S1

rtr-c (*, 224.1.1.1) Mcast Traffic

171.68.28.190

(*, (*, 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: TT 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

rtr-a

S1

rtr-b

S3 S0

S1

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 OIL’s of all (S,G) entries are always kept in sync with their parent (*, G). Note: When the (S, G) OIL’s 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

rtr-a

S1

S3 S1

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: TT 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

rtr-a

S1

S3 S1

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

rtr-a

rtr-b

S1

S3 S1

E0

rtr-c (*, 224.1.1.1) Mcast Traffic

1 IGMP Join Rcvr A

1•

“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

rtr-a

rtr-b

S1

S3 S1

E0

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

Added Interfaces

(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

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 OIL’s 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

rtr-a

rtr-b

S1 E0

2

S3 S1

rtr-c

(*, G) Join

(*, 224.1.1.1) Mcast Traffic

Rcvr A

2•

“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

rtr-a

rtr-b

S1

S3 S1

E0

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 OIL’s 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

rtr-a

rtr-b

S1

S3 S1

E0

rtr-c (*, 224.1.1.1) Mcast Traffic

3 Rcvr A

3•

Group G traffic begins to flow to “Rcvr A”. (Note: 171.68.37.121 traffic doesn’t flow to RP then back down to rtr-b)

Module5. ppt

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

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

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

79 79

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.

80 80

8/10/2001 2:37 PM

• 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 Group’s 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 –– IfIf 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:

–– IfIf “J” “J” flag flag set set in in (*, (*, G) G) •• •• ••

Module5. ppt

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)

©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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

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

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B (*, 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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

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

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr 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 switch Module5. ppt

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

8/10/2001 2:37 PM

85 85

• 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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

10.1.2.2

rtr-d

E0

E1

E0

E010.1.2.1 1 Group “G” rate > Threshold (Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B (*, 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

2

Group “G” rate exceeds SPT Threshold at “rtr-b”; Set J Flag in (*, G) and wait for next (Si,G) packet.

Module5. ppt

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

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

10.1.2.2

rtr-d

E0

E1

E0

E010.1.2.1 3 (Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B (*, 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

4

(Si,G) packet arrives down Shared tree. Clear J Flag in the (*,G) & create (Si,G) state.

Module5. ppt

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

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr 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

J Flag indicates (S, G) created by exceeding the SPT-threshold

(171.68.37.121/32, 224.1.1.1), 00:00:28/00:02:51, flags: CJT CJT Incoming interface: Ethernet0, RPF nbr 10.1.2.1 Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:28/00:02:32

New State in “rtr-b” Module5. ppt

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

88 88

8/10/2001 2:37 PM

• 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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

10.1.2.2

rtr-d

E0

E1

E0

E010.1.2.1 5 (Si,G) Join (Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

5

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

6 (Si,G) Join

S0

10.1.4.2

S0

To Source “Si ”

S1

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

6

“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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

7 (S ,G) Traffic i

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

6 7

“rtr-a” forwards (Si,G) Join toward Si. (Si, G) traffic begins flowing down SPT tree.

Module5. ppt

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

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)

rtr-c 10.1.4.1

S1

S0

8

(Si,G)RP-bit Prune

S2

rtr-a

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

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.

Module5. ppt

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

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

9

S0

10.1.4.2

S0

To Source “Si ”

S1

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

•9 Unnecessary (Si, G) traffic is pruned from the Shared tree.

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)

rtr-c 10.1.4.1

rtr-a

S1

S0 S2

10

To Source “Si ”

S1

S0

10.1.4.2

S0

E010.1.2.1

10.1.2.2

rtr-d

E0

E1

E0

(Si, G) Traffic Flow Shared (RPT) Tree

rtr-b

Rcvr A

SPT Tree

Rcvr B

•9 Unnecessary (Si, G) traffic is pruned from the Shared tree. 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

–– IfIf “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 •• IfIf rate rate

...

Module12. ppt

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

8/21/2001 3:39 PM

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

28 28

Module7.ppt

28

URD – Host Signalling Users Desktop 3... It will retrieve this URL and see from the content-type (NOT HTML!), that this is input for an application that it has to start (or run as a plugin)

Users favourite Browser Thank you for choosing this Sports channel

HTTP connection to sessions.broadcast.com for /sports.sdp

GET /sports.sdp HTTP/1.0 ...

Content-type: application/x-sdp Content-length: … … i=Sports Channel c=232.3.4.5 ……...

Actual URL content

Transferring from sessions.broadcast.com Module12. ppt

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

8/21/2001 3:39 PM

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

29 29

Module7.ppt

29

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel

4. The browser will look into his application mappings for this content-type x-sdp, and start the appropriate application - our old player. Transferring from sessions.broadcast.com Module12. ppt

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

8/21/2001 3:39 PM

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

30 30

Module7.ppt

30

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel

… i=Sports Channel c=232.3.4.5 ……...

4… While doing so, the browser will also hand over the Actual URL content to that application (typically in a file as a command line argument for the application). Transferring from sessions.broadcast.com Module12. ppt

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

8/21/2001 3:39 PM

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

31 31

Module7.ppt

31

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel

5. From this URL, the application knows the multicast group IGMPv1/v2 to use, and it will Join Group join to that group. 232.3.4.5 Module12. ppt

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

Transferring from sessions.broadcast.com 8/21/2001 3:39 PM

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

32 32

Module7.ppt

32

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel

6. But the application will not yet receive traffic, because it is an IP SSM group, and this old applications group membership report is not good enough alone ! Module12. ppt

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

Transferring from sessions.broadcast.com 8/21/2001 3:39 PM

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

33 33

Module7.ppt

33

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel Currently showing Euro 2000 Soccer live from Brussels

7. Back to the browser who continues to interpret and display his original HTML page... Transferring from sessions.broadcast.com Module12. ppt

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

8/21/2001 3:39 PM

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

34 34

Module7.ppt

34

URD – Host Signalling Users Desktop

Users favourite Browser Thank you for choosing this Sports channel

View source: http:/www.broadcast.com/sports.htm

...