Cisco - IP Multicast Course PDF
Cisco - IP Multicast Course PDF
Cisco - IP Multicast Course PDF
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.
Layer 2 Campus Design - Module 2 now contains material on the design issues relating to IP
Multicast over campus networks including topics such as CGMP, IGMP Snooping, IGMPv3,
mutlicast over ATM-LANE, and general Layer 2 "gotchas" that need to be avoided.
Rendezvous Points - Module 6 is devoted to this topic and will help you answer that age old
question, "Where do I put my RP?" This module covers the use of various RP techniques such
Static RP's, Auto-RP and BSR as well as how to tune and debug these mechanisms.
Advanced IP Multicast Features - Module 7 is a module that is chocked full of advanced multicast
topics including, IP Multicast Helper, dealing with Rate-Limits, Admin. Scoping and many others.
A real "must" read for people that are serious about extracting the absolute maximum performance
out of their multicast network
Multiprotocol BGP (MBGP) - Module 10 covers the use of MBGP for Inter-domain IP Multicast.
Even if you are not already a BGP guru, you will find this module very helpful as it contains a short
overview on BGP that will give the beginner to Inter-domain IP Multicasting the necessary
background on BGP to get started.
Multicast Source Discovery Protocol (MSDP) - Module 11 highlights MSDP and how it is
currently being used in the Internet to interconnect independent PIM Sparse mode domains so that
true Inter-domain IP Multicast can be accomplished.
PIM Protocol Extension - Module 12 is an entirely new module that describes two of the latest
extensions to the PIM protocol; Source-Specific Multicast (SSM) and Bidirectional PIM (Bidir).
These two new extensions allow PIM to scale better in several different ways.
These IP Multicast training modules have previously been used for internal Cisco training only. Due to the
tremendous demand for this information, we have made this content available for "self-training" purposes
by our customers. All of this material is copyrighted and may not be repackaged or resold for any
commercial purposes without written permission from Cisco Systems.
All modules are constantly being updated to improve their content and/or correct any mistakes in the
material. You may wish to check this page from time to time to download updated versions of the material.
The following training modules are all in Adobe PDF format. To view them, use Adobe Acrobat Reader. If
file://D:\Lucho\xx\index.html 01/03/2003
Course Presentation Material Pgina 2 de 2
you don't have Acrobat Reader on your workstation you may download a free version from Adobe.
file://D:\Lucho\xx\index.html 01/03/2003
Fundamentals of
IP Multicast
Module 1
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 1
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 2
2
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 3
3
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 4
4
Unicast
Host
Router
Multicast
Host
Router
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 5
5
Optimized Performance
Performance: Eliminates traffic redundancy
Distributed Applications
Applications: Makes multipoint applications possible
Unicast
0.8
0.6
Traffic
0.4
Mbps
0.2
0
1 20 40 60 80 100
# Clients
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 6
6
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 side-
effects 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.
ing Training
renc
nfe
Co nd
Wh
iteb ideo
-Dema
oar V On
d/C eo -
olla Vid
bor
Real--Time Data Delivery
Real DeliveryFinancial atio
n
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 8
8
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 10
10
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 11
11
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 12
12
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.
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 14
14
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 15
15
IP group addresses
Class D addresshigh-order 3 bits are set (224.0.0.0)
Range from 224.0.0.0 through 239.255.255.255
Well known addresses designated by IANA
Reserved use: 224.0.0.0 through 224.0.0.255
224.0.0.1all multicast systems on subnet
224.0.0.2all routers on subnet
See ftp://ftp. isi.edu/in-notes/ iana/assignments/multicast-addresses
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 16
16
Eamples:
224.0.0.1 All Hosts
224.0.0.2 All Multicast Routers
224.0.0.3 All DVMRP Routers
224.0.0.5 All OSPF Routers
224.0.0.6 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.
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 17
17
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 18
18
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 19
19
A B D F
C E
Receiver 1 Receiver 2
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 20
20
A B D F
C E
Receiver 1 Receiver 2
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 21
21
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.
A B D (RP) F
Receiver 1 Receiver 2
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 22
22
Source 2
A B D (RP) F
Receiver 1 Receiver 2
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 23
23
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
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 25
25
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)
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
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).
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 27
27
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
Source
151.10.3.21
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 29
29
X
S0
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 30
30
S1 S2
RPF Check Succeeds! E0
Unicast Route Table
Network Interface
151.10.0.0/16 S1 Packet Arrived on Correct Interface!
198.14.32.0/24 S0 Forward out all outgoing interfaces.
204.1.16.0/24 E0
(i. e. down the distribution tree)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 31
31
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 32
32
TTL-Thresholds
Non-Zero, Multicast, TTL-Thresholds may be set on any multicast capable
interface.
IP multicast packets whose TTLs (after being decremented by one by normal router
packet processing) are less than the TTL -Threshold on an outgoing interface, will
be not be forwarded out that interface.
Zero Multicast TTL implies NO threshold has been set.
TTL-Threshold Application
Frequently used to set up multicast boundaries to prevent unwanted multicast traffic
from entering/exiting the network.
TTL-Threshold = 16 S0 X
Packet not forwarded!
S1 S2
E0 TTL-Threshold = 64
TTL-Threshold = 0
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 33
33
TTL-Threshold Example
In the above example, the interfaces have been configured with the following TTL -
Thresholds:
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.
Serial0 Serial1
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.
Company ABC
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.
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
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 38
38
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 39
39
33 mrouted
1 1 3
33 35
1 2
mrouted mrouted mrouted
C D 34 E
2 35 Y
3
2 mrouted
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 42
42
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 43
43
mrouted mrouted
X
mrouted
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 44
44
Receiver 1
(Group G)
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.
Receiver 1
(Group G)
Receiver 1
(Group G)
Receiver 1
(Group G)
mrouted mrouted
X
mrouted
Receiver 1
(Group G)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 50
50
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 51
51
MABR1 MABR2
Area 1 Area 2
MA MB MA MA
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 52
52
MB
MA M B (S1 , B) MA M A (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 53
53
Intra-Area Multicast
Once all routers within the area have learned where all members are in the network
topology, it is possible to construct Source-network trees for multicast traffic
forwarding.
Example
In the above example, Source S1 in Area 1 begins sending multicast traffic to
Group B. As this data reaches the the routers in the area, each runs a Dijkstra
calculation and computes a Shortest Path Tree rooted at the network for S1 and
that spans all the members of Group B. The results of these calculations are used
to forward the (S1, B) traffic as seen in Area 1 above.
In Area 2, Source S2 begins sending multicast traffic to Group A. Again, the
routers in the area use the Group-Membership information in their MOSPF
database to run a Dijkstra calculation for the source network where S2 resides
and create a Shortest Path Tree for this traffic flow. The results are then used to
forward (S2, A) traffic as shown.
Notice that the routers in Area 2 are not aware of the member of Group A in Area
1 because Membership LSAs are not flooded between these two areas. This Inter-
Area traffic flow is handled by another mechanism that is described in the next few
pages.
MB
MA M B (S1 , B) MA M A (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 54
54
Wildcard Receivers
In order to get multicast traffic to flow between Areas, the concept of Wildcard
Receivers is used by MOSPF Area Border Routers (MABR).
Wildcard Receivers set the Wildcard Receiver flag is in the Router LSAs that they
inject into the Area. This flag is equivalent to a wildcard Group Membership LSA
that effectively says, I have a directly connected member for every group.
MABR1 MABR2
Area 1 Area 2
MB
MA M B (S1 , B) MA M A (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 55
55
MA M B (S1 , B) MA M A (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 56
56
MABR1 MABR2
Area 1 Area 2
MB
MA M B (S1 , B) MA M A (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 57
57
Unnecessary traffic
still flowing to the
MABR Routers!!
Wildcard Receiver Flag Wildcard Receiver Flag
(*, *) (*, *)
MABR1 MABR2
Area 1 Area 2
(S1 , B) (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 58
58
MABR1 MABR2
Area 1 Area 2
MA MB MA MA
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 59
59
Inter-Domain Traffic
Inter-domain multicast traffic flow basically follows the same mechanisms that were
used for Inter-Area traffic flows.
Summary Membership LSAs inform the routers in the backbone of which MABRs
has members of which groups.
MABR1 MABR2
Area 1 Area 2
MB
MA MB MA MA
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 60
60
(S1 , B) (S2 , A)
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 61
61
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 62
62
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
Source
Receiver
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 64
64
Source
Multicast Packets
Prune Messages
Receiver
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 65
65
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 66
66
S0 S0
2 2
Assert Assert
E0 1 E0
<distance, metric> <distance, metric>
Source
RPF Interface
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 68
68
Interface Fails
X
Source
RPF Interface
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 69
69
X
Source
But wait . . .
This Router still
hasnt converged yet
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 70
70
Receiver Receiver
Multicast Packets
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 71
71
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
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
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
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 76
76
RP
Receiver
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 78
78
RP
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 79
79
RP
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 80
80
RP
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 81
81
RP
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 82
82
RP
Source
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 83
83
RP
Source
Module1.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 84
84
RP
Source
Module1.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 85
85
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 86
86
Module1. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 3:45 PM 87
87
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
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.
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 1
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 2
2
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 3
3
IP group addresses
224.0.0.0239.255.255.255
Class D addresses = high order
bits of 1110
Special reserved group addresses:
224.0.0.0224.0.0.255:
224.0.0.1 All systems on this subnet
224.0.0.2 All routers on this subnet
224.0.0.4 DVMRP routers
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 4
4
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
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
224.1.1.1
224.129.1.1
225.1.1.1 1 - Multicast MAC Address
225.129.1.1 (FDDI and Ethernet)
.
. 0x0100.5E01.0101
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 6
6
224.x.x.x 224.x.x.x
c0-00-00-04-00-00 ff-ff-ff-ff-ff-ff
(Shown in Token Ring, non-canonical format)
224.0.1.0
224.0.1.1
224.0.1.2 1 - Multicast MAC Address
224.0.1.3 (Token Ring)
.
. 0xFFFF.FFFF.FFFF
.
239.239.255.252
239.255.255.253
239.255.255.254 RUN AWAY ! ! !
239.255.255.255
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 8
8
interface token-ring 0
ip pim sparse Use Functional Address
ip multicast use-
use -functional 0xc000.0004.000
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.
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.
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
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.
H1 H2 224.1.1.1 H3
Report
IGMPv1
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.
H1 H2 H3
General Query
to 224.0.0.1
IGMPv1 Multicast
Router
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.
X X
Suppressed Report Suppressed
#3 #2 #3
Query to
224.0.0.1 #1
IGMPv1
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.)
H1 H2 H3
Query to
224.0.0.1
IGMPv1
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.
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.
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.
Group Address
Type:
0x11 = Membership Query
0x12 = Version 1 Membership Report
0x16 = Version 2 Membership Report
0x17 = Leave Group
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.
H1 224.1.1.1 H2 H3
Report
1.1.1.1
rtr-a
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.
H1 H2 H3
1.1.1.1
rtr-a
IGMP State in rtr-a
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 21
21
H1 H2 H3
Querier Election
In IGMPv1 there was no formal IGMP querying router election process in within
IGMPv1 itself - it was left up to the multicast routing protocol and different
protocols used different mechanisms. This would often result in multiple queriers
on a single multiaccess network. With the definition of IGMPv2 a formal querying
router election process was specified within the IGMPv2 protocol itself.
In IGMPv2 each router on a multiaccess network will initially assume it is the
querier and begin sending queries. Each router will see the queries from the
other IGMPv2 routers and will examine the IP address of these queries. All
IGMPv2 routers will then defer to the router with the lowest IP address.
In other words, the IGMPv2 router with the lowest IP address will become the
querying router.
Finally, if the currently elected Query Router fails to issue a query within a
specified time limit, a timer in the other IGMPv2 routers will time-out and cause
them to re-initiate the Query Election process.
Group Specific Queries
IGMPv2 also added the concept of Group Specific Queries. This is
accomplished by sending the IGMPv2 Membership Query to the Groups
multicast address as opposed to sending to the All Hosts (224.0.0.1) multicast
address as is done for IGMPv2 General Queries.
Query Interval
Membership queries are sent every 60 seconds (default).
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 23
23
1.1.1.1 Query
IGMPv2
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.)
H1 H2 H3
1.1.1.1
rtr-a
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 25
25
IGMPv2 Leaves
In the above example, notice that the router is aware that there one or more
members of group 224.1.1.1 active on Ethernet0 and that Host 2 responded with
a Group Membership Report for this group during the last General Query
interval. (Indicated by the IP address of Host 2 in the Last Reporter field.)
Leave to Report to
#1 224.0.0.2 #3 224.1.1.1
IGMPv2 Leaves
In IGMPv1, hosts would leave passively - i.e.. they do not explicitly say they are
leaving - they just stop reporting. However, IGMPv2 has explicit Leave Group
messages.
When the IGMPv2 Query router receives a Leave Message, it responds by
sending a Group Specific Query for the associated group to see if there are still
other hosts wishing to receive traffic for the group. This process helps to reduce
overall Leave Latency.
When CGMP is in use, the IGMPv2 Leave Message mechanism also helps the
router to better manage the CGMP state in the switch. This also improves the
leave latency for the specific host at layer 2.
(Note: Due to the wording of the current IGMPv2 draft specification, hosts may
chose to NOT send Leave messages if they are not the last host to leave the
group. This can adversely affect CGMP performance.)
Example :
H2 and H3 are members of group 224.1.1.1
#1 - H2 leaves
#2 - Router sends group specific query to see if any other group members
are present.
#3 - H3 hasnt left yet so it responds with a Report message.
Router keeps sending multicast for 224.1.1.1 since there is >= 1 member
present
H1 H2 H3
1.1.1.1
rtr-a
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 27
27
IGMPv2 Leaves
At this point, the group is still active. However, the router shows that Host 3 is
the last host to send an IGMP Group Membership Report.
Leave to
#1 224.0.0.2
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.)
H1 H2 H3
1.1.1.1
rtr-a
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 29
29
IGMPv2 Leaves
At this point, all hosts have left the 224.1.1.1 group on Ethernet0. This is
indicated by rtr-a above.in the output of the show ip igmp group command.
Query
Resp.
Interval
Query Interval
interface Ethernet 0
ip pim sparse Tuning the Query Response
ip igmp query-
query -max
max-
-response
response-
-time 20 Interval
(Default = 10 secs)
interface Ethernet 0
ip pim sparse Tuning the Query Interval
ip igmp query-
query -interval 120 (Default = 60 secs)
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 32
32
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 33
33
IGMPv1
Report #2
1.1.1.1 IGMPv1 #1
Query
IGMPv1
Host H2:
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 34
34
224.1.1.1
Report
1.1.1.1
IGMPv2 Router A
Router A:
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 35
35
H1 H2 H3
1.1.1.1 1.1.1.2
IGMPv2 IGMPv1
Router A Router B
Router A:
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 36
36
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.
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 37
37
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.
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.
S Flag .
.
Suppresses processing by routers .
QRV (Querier Robustness Value)
Source Address [N]
Affects timers and # of retries
QQIC (Queriers Query Interval)
Same format as Max. Resp. Time
Number of Sources (N)
(Non-zero for Group-and-Source Query)
Source Address
Address of Source
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 40
40
Type
The same IGMPv2 type code 0x11 is used as the IGMPv3 Membership Query
Type code.
Max. Response Time (1/10 seconds)
This field has been reformatted to permit longer times to be expressed. If the
value is < 128, the the time is absolute (.1- 12.8 seconds). If the value is > 128, it
is interpreted as a floating-point number as follows:
+-+-+-+-+-+-+-+-+
|1| exp | mant | value = (mant|0x10)<<(exp+3)
+-+-+-+-+-+-+-+-+
Group Address
This field is identical to the IGMPv2 version of this field. It is set to 0.0.0.0 for
General Queries.
S Flag
Indicates that the routers that receive this message should not process it.
QRV (Querier Robustness Value)
This value causes all hosts to adjust their Robustness Values which in turn
affect various timers and retry counts. Increasing this value provides more
protocol robustness at the expense of latency.
QQIC (Querier Query Interval)
This field indicates the Query Interval in use by the Querying router. Its format is
the same as the Max. Response Time field.
Number of Sources
The number of Source Addresses in the Group-and-Source-Specific Query.
Record Type
# of Group Records (M) Include, Exclude, Chg-to-Include,
Number of Group Records in Report Chg-to-Exclude, Add, Remove
Group Records 1 - M # of Sources (N)
Group address plus list of zero or Number of Sources in Record
more sources to Include/Exclude
(See Group Record format) Source Address 1- N
Address of Source
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 41
41
# of Group Records
Indicates the number of Group records that are contained in the Membership
Report. IGMPv3 Membership Reports can contain IGMP state on a number of
Groups and Sources within the group. The source information specifies which
Sources to Include or Exclude.
Aux. Data Length (Group Records)
Indicates the size of the Auxilliary Data area.
Multicast Address (Group Records)
The multicast group address of the joined Group.
# of Sources (Group Records)
Indicates the number of Sources in the list.
H1 wants to
receive only S =
1.1.1.1 and no
other.
R3
With IGMP,
specific sources IGMPv3:
can be joined. S = Join 224.1.1.1
1.1.1.1 in this case Include: 1.1.1.1
Module2. ppt
H1 - Member of 224.1.1.1
1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 42
42
IGMPv3 Example
In this example, host H1 wishes to join group 224.1.1.1 but only wishes to
receive traffic from Source 1.1.1.1. The IGMPv3 host can signal the designated
router, R3, that it is only interested in multicast traffic from Source 1.1.1.1 for
Group 224.1.1.1. Router R3 could then potentially prune the unwanted
source, 2.2.2.2,.
H1 H2 H3
1.1.1.1
rtr-a
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 43
43
Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in
an unsolicited IGMPv3 Membership Report indicating their interest. This
reduces join latency for the end system joining if no other members are present.
In the example above, Host 2 is joining multicast group 224.1.1.1 and is
willing to receive any and all sources in this group.
H1 H2 H3
1.1.1.1
rtr-a
H1 H2 H3
1.1.1.1
rtr-a
H1 H2 H3
1.1.1.1 Query
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 46
46
Query-Response Process
The router multicasts periodic Membership Queries to the All-Hosts (224.0.0.1)
group address.
All hosts on the wire respond by sending back an IGMPv3 Membership Report
that contains their complete IGMP Group state for the interface.
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 47
47
L2 Multicast Switching
For most L2 Switches, Multicast traffic is normally treated like an unknown MAC
address or Broadcast frame which causes the frame to be flooded out every port
within a VLAN at rates of over 1 Mbps. This is fine for unknowns and broadcasts
but as we have seen earlier, IP Multicast hosts may join and be interested in
only specific multicast groups. Again, on most L2 Switches, all this traffic is
forwarded out all ports resulting in wasted bandwidth on both the segments and
on the end stations.
One way around this on Catalyst Switches is using the Command Line Interface
to program the switch manually to associate a multicast MAC address with say
ports 5,6,7 so only ports 5,6,and 7 receive the multicast traffic destined for the
multicast group. This works fine but again we know IP Multicast hosts
dynamically join and leave groups using IGMP to signal to the Multicast Router.
This static way of entering the multicast information is not very scaleable.
Dynamic configuration of the Switches forwarding tables would be a better idea,
and cut down on user administration.
IGMP
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 48
48
Router A
1
LAN Switch
Switching
0 Engine
CPU
CAM
Table
2 3 4 5
MAC Address Port
0000.6503.1d0e 5
Router A
IGMP Report
224.1.2.3
1
LAN Switch (IGMP Snooping Enabled)
Switching
0 Engine
CPU
CAM
Table
2 3 4 5
MAC Address Ports
Router A
1
LAN Switch (IGMP Snooping Enabled)
Switching
0 Engine
CPU
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 0,1,2
Router A
IGMP Report
224.1.2.3
1
LAN Switch (IGMP Snooping Enabled)
Switching
0 Engine
CPU
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 0,1,2
Router A
1
LAN Switch (IGMP Snooping Enabled)
Switching
0 Engine
CPU
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 0,1,2,5
6Mbps !!!
Choke, Gasp, Router A
Wheeze!!
1
LAN Switch (IGMP Snooping Enabled)
Switching
0 Engine
CPU
6Mbps
MPEG Video
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 0,1,2,5
Router A
1
LAN Switch (IGMP Snooping Enabled)
Switching Engine
0 (w/L3 ASICs)
CPU
CAM
Table
2 3 4 5
MAC Address L3 Ports
0100.5exx.xxxx IGMP 0
Router A
1
LAN Switch (IGMP Snooping Enabled)
Switching Engine
0 (w/L3 ASICs)
CPU
IGMP Report
224.1.2.3
CAM
Table
2 3 4 5
MAC Address L3 Ports
0100.5exx.xxxx IGMP 0
0100.5e01.0203 !IGMP 1,2
Router A
IGMP Report
224.1.2.3
1
LAN Switch (IGMP Snooping Enabled)
Switching Engine
0 (w/L3 ASICs)
CPU
CAM
Table
2 3 4 5
MAC Address L3 Ports
0100.5exx.xxxx IGMP 0
0100.5e01.0203 !IGMP 1,2,5
6Mbps
MPEG Video
CAM
Table
2 3 4 5
MAC Address L3 Ports
0100.5exx.xxxx IGMP 0
0100.5e01.0203 !IGMP 1,2,5
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 59
59
Solution 2: CGMP
CGMP is based on a client server model where the router can be considered a CGMP
server and the switch taking on the client role. There are software components running
on both devices, with the router translating IGMP messages into CGMP commands
which are then executed on the Catalyst 5000 NMP and used to program the EARLs
forwarding tables with the correct Multicast entries.
Since the hosts and routers use well-known IP Multicast Addresses, the EARL can be
preprogrammed to direct IGMP Control packets both to the router and the NMP. We will
see the NMPs use of these IGMP control packets in a later slide.
The basis of CGMP is that the IP Multicast router sees all IGMP packets and therefore
can inform the switch when specific hosts join or leave Multicast groups. The switch then
uses this information to program its forwarding table.
When the router sees an IGMP control packet it creates a CGMP packet that contains
the request type (Join or Leave), the Layer 2 Multicast MAC Address, and the actual
MAC address of the client.
This packet is sent to a well known address which all CGMP switches listen on. It is then
interpreted and the proper entries created in the switchs CAM Table to constrain the
forwarding of multicast traffic for this group.
(a) (b)
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 60
60
CGMP Example
In this example - the client will asynchronously send an IGMP Membership
Report when it wants to join the group.
The Router converts this IGMP Membership Report into a CGMP Join
containing:
USA - Unicast Source Address
GDA - Group Destination Address
The CGMP Join is multicast to a well-known (non-IP) multicast MAC address
which the switch listens on.
GDA
GDA USA
USA
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 61
61
CAM
Table
2 3 4 5
MAC Address Ports
Router A
1
Simple LAN Switch
Switching
CPU 0 Engine
CGMP Join
USA 0080.c7a2.1093
CAM GDA 0100.5e01.0204
Table
2 3 4 5
MAC Address Ports
Router A
1
Simple LAN Switch
Switching
CPU 0 Engine
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 1,2
Router A
IGMP Report
224.1.2.3
1
Simple LAN Switch
Switching
CPU 0 Engine
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 1,2
Router A
1
Simple LAN Switch
Switching
CPU 0 Engine
CGMP Join
USA 0080.c7b3.2174
CAM GDA 0100.5e01.0204
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 1,2
Router A
1
Simple LAN Switch
Switching
CPU 0 Engine
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 1,2,5
Router A
1
Simple LAN Switch
Switching
CPU 0 Engine
6Mbps
MPEG Video
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e01.0203 1,2,5
Mcst MAC Client MAC Join Add USAs port to the Group
Mcst MAC Client MAC Leave Delete USAs port from Group
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 69
69
CGMP Messages
All of these messages are sent by the router (switches do not originate CGMP
messages)
All of these messages are contained within a given VLAN
When a JOIN is sent with a non-zero GDA and a non-zero USA, this adds the
switch port where USA is located to the given group list in the CAM table
(normal operation after a router receives an IGMP JOIN)
When a LEAVE is sent with a non-zero GDA and a clients MAC address for the
USA, that clients port is deleted from the group (selectively delete a single client
based on an IGMP leave)
When a JOIN is sent with a GDA of all zeros using its own MAC address as the
USA, this is an advertisement for the switches to detect what incoming switch
ports are router ports (occurs every 60 seconds so switches can dynamically
find the CGMP-speaking routers)
When a LEAVE is sent with an all-zeros GDA and a USA of the routers MAC, all
groups and ports are deleted that are associated with that router port (the router
has withdrawn its CGMP ability)
When a LEAVE is sent with a non-zero GDA and an all zeros USA, this globally
deletes the group in all switches (used to globally delete the group after the last
member has left via IGMP state)
When a LEAVE is sent with all zeros in GDA and USA, all groups are deleted in
all switches (occurs when CGMP is disabled on the router or a clear ip cgmp is
executed for a given router interface/VLAN)
Command Notes
ip cgmp Enable CGMP per (Sub) Interface
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 70
70
Command Notes
Command Notes
set multi router <mod/port> Designates port a router port
IGMP snooping
Switches with Layer 3 aware ASICs
High-throughput performance maintained
Increases cost of switches
Switches without Layer 3 aware ASICs
Suffer serious performance degradation
CGMP
Requires Cisco routers and switches
Can be implemented in low -cost switches
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 73
73
Summary
IGMP Snooping can actually provide some performance optimizations over
CGMP. However, it requires switches that are implemented with more costly
Layer 3 aware ASICs in order to avoid performance impacts.
CGMP is a proprietary protocol that is only implemented on Cisco routers and
switches and does not have quite as many performance optimizations that IGMP
Snooping can offer. However, it is the ONLY choice if one desires to provide
Layer 2 multicast traffic constraint on low-end switches such as the Cisco
Catalyst 1900 or other equivalent switches.
Unnecessary Traffic!!!
Catalyst 5000
Catalyst
29xx
Catalyst 29xx Catalyst 29xx
Video Server
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 74
74
Video Server
Catalyst 5000
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 75
75
Router B Router C
7500 Unnecessary 7500
Multicast
Traffic !!!
Receiver Receiver
Group 1 Group 2
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 76
76
7500 T1
1.5MB WAN
2500
2500
MPEG
Video Router-D
Streams
Move WAN Router to
Another VLAN Segment
Catalyst 5000
Inside of Catalyst 5000
Router B Router C
7500 Unnecessary 7500
Multicast
Traffic !!!
Receiver Receiver
Group 1 Group 2
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 77
77
Answer to Exercise 1: Because there is no other router on the LA N segment, Router A is able to Prune off
the traffic flow without the Prune being overridden by another router on the LAN
segment.
Problem
Routers send PIM Join/Prunes at Layer 3
IGMP Join/Leaves not sent by routers
Other routers on VLAN can override Prune
Switches operate at Layer 2
Use IGMP Snooping to constrain multicast
Must assume routers want all multicast traffic
Need new Layer 2 Join/Prune mechanism
Permits routers to send Join/Prunes to switch
Solution: (RGMP)
Router Group Management Protocol
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 78
78
CAM
Table
1 2 3 4
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 80
80
RGMP Example:
Consider the LAN segment running through the above switch that has four
routers connected in a core router backbone.
Initially, RGMP blocks all multicast traffic from reaching the routers by the
wildcard CAM table entry.
CAM
Table
1 2 3 4
Entry Added
PIM (*, 224.1.1.1) Join
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 81
81
RGMP Example:
When router B receives a downstream PIM (*,G) Join for group 224.1.1.1, it
sends an RGMP Join for the corresponding MAC address, 0x0100.5e01.0101.
When the switch receives the RGMP Join message, it instantiates an entry in its
CAM table for 0x0100.5e01.0101 with the port number of the sending router.
CAM
Table
1 2 3 4
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 82
82
RGMP Example:
When router D receives a downstream PIM (*,G) Join for group 224.1.1.1, it too
sends an RGMP Join for the corresponding MAC address, 0x0100.5e01.0101.
When the switch receives the RGMP Join message from router D, it updates the
entry in its CAM table for 0x0100.5e01.0101 by adding the port number
associated with router D.
CAM
Table
1 2 3 4
Source
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 83
83
RGMP Example:
When a source behind router B begins transmitting to group 224.1.1.1, router B
forwards this traffic to the core router backbone (the switch).
The CAM table entry in the switch now effectively constrains the multicast traffic
to routers B and D. Routers A and C, which have not joined the multicast group,
do not receive the traffic.
CAM
Table
2 3 4 5
MAC Address Ports
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 84
84
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e00.0005 2
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 85
85
CAM
Table
2 3 4 5
MAC Address Ports
0100.5e00.0005 2
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 86
86
224.0.0.x
224.128.0.x
225.0.0.x 1 - Multicast MAC Address
225.128.0.x
.
. 0x0100.5E00.00xx
.
238.0.0.x
238.128.0.x
239.0.0.x
239.128.0.x
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 87
87
224.1.1.1
224.129.1.1
225.1.1.1 1 - Multicast MAC Address
225.129.1.1
.
. 0x0100.5E01.0101
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 88
88
BUS
Unwanted Data!!!
Source
Member
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 90
90
BUS
1.5Mbit
MPEG
Video
Make Sure Your ATM
Switches Can Replicate
Source
Cells at this Rate! Member
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 91
91
Why do I have to
do all the work?!
ELAN 1 ELAN 2
BUS
Avoid using a
single device as
BUS for multiple
ELANs ELAN 3
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 92
92
Design issues
BUS horsepower is critical
Use separate BUS device per ELAN to reduce load
Overloaded BUS = cell/packet loss and jitter/delay
Can cause problems on multimedia conferences
ATM switch cell replication rate is critical
Switches that replicate cells in hardware are best
Add lots of bandwidth to ATM fabric
Traffic will frequently be sent where its unwanted
ATM core bandwidth will be wasted
P2MP VCs may be a better solution
Module2. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/9/2001 4:20 PM 93
93
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 1
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 2
2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 3
3
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 4
4
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 5
5
Source
Receiver
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 6
6
Initial Flooding
In this example, multicast traffic being sent by the source is flooded throughout
the entire network.
As each router receives the multicast traffic via its RPF interface (the interface in
the direction of the source), it forwards the multicast traffic to all of its PIM-DM
neighbors.
Note that this results in some traffic arriving via a non-RPF interface such as the
case of the two routers in the center of the drawing. (Packets arriving via the
non-RPF interface are discarded.) These non-RPF flows are normal for the
initial flooding of data and will be corrected by the normal PIM-DM pruning
mechanism.
Source
Multicast Packets
Prune Messages
Receiver
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 7
7
Source
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 8
8
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 9
9
PIM Registers
PIM Register-Stop
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 10
10
Ver. Reserved
Type:
0x14 = PIM Message
Code:
PIMv1 used 0 = Router-Query
1 = Register (SM only)
IGMP Packets 2 = Register-Stop (SM only)
3 = Join/Prune
4 = RP-Reachibility (SM only)
5 = Assert
6 = Graft
7 = Graft-ACK
Ver:
PIM Version = 1
PIMv1 messages are multicast to the ALL-Routers (224.0.0.2) group with a TTL
of 1.
Note: (PIMv1 packet formats are not shown. Only PIMv2 packets will be given.)
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 11
11
Ver:
PIM Version = 2
Type:
0 = Hello
1 = Register (SM only)
2 = Register-Stop (SM only)
3 = Join/Prune
4 = Bootstrap (SM BSR only)
5 = Assert
6 = Graft (DM only)
7 = Graft-Ack (DM only)
8 = C-RP-Announcement (SM BSR only)
3 7 15 31
Ver. Type Reserved Checksum
Option Type Option Length
Option Value
...
Option Types:
1 = Holdtime (Period of time in seconds before this PIM
neighbor times out.)
19 = DR Priority
20 = Generation ID
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 13
13
Group List:
List (by group) of sources
to Join and/or Prune
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 14
14
Group Lists
Group Lists are used in Join/Prune messages as well as Graft and Graft -Ack
messages.
A Group List is a list of Group entries each beginning with a Group IP Address
and Group mask to identify the Multicast Group.
Each Group List entry contains a list of zero or more sources to Join followed by
a list of zero or more sources to Prune.
Group IP Address
Number of Join Sources
Number of Prune Sources
Join List
Prune List
The addresses used in Join and Prune lists use a special encoded format that
allows for other protocols besides IPv4. (See next slides.)
Addr Family:
IANA Address Family Identifier (1=IPv4)
Encoding Type:
Type of encoding within Address Family
Unicast Address :
Unicast Address of the target device.
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 16
16
Address Family
Indicates the IANA Address Family Identifier. For IPv4, this value is 1.
Encoding Type
Indicates the encoding type within the Address Family.
Unicast Address
IP unicast address of the target device.
Addr Family:
IANA Address Family Identifier (1=IPv4)
Encoding Type:
Type of encoding within Address Family
S = Sparse Mode bit :
Indicates sparse mode group. Rcvrs must send periodic joins.
W = Wildcard bit :
Indicates join/prune applies to (*, G) entry.
R = RP bit :
Indicates this join/prune should be sent up the Shared Tree towards the RP.
Mask Length:
Number of bits in the prefix of the Group Address.
Source Address :
Address of Multicast Source.
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 17
17
Addr Family:
IANA Address Family Identifier (1=IPv4)
Encoding Type:
Type of encoding within Address Family
Mask Length:
Number of bits in the prefix of the Group Address.
Group Address :
Multicast Group Address.
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 18
18
Group List:
List (by group) of sources
to Graft or Graft-Ack
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 19
19
R Metric Preference
Metric
Group Address:
Identifies Group of the Assert
Source Address:
Identifies Source of the Assert
R: (Sparse Mode)
1 = Assert down RP Tree; 0 = Assert Down SPT
Metric Preference:
Admin. Distance of unicast routing protocol
Metric:
Unicast routing protocol metric
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 20
20
B = Border Bit:
Indicates DR is a border router performing a proxy-register
N = Null Register Bit:
Indicates DR is sending a Null-Register before expiring its
register-suppression timer.
Multicast Data Packet:
The original packet sent by the source. For periodic sending of
registers, this part is null.
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 21
21
Group Address:
The group address from the register message.
Source Address:
IP host address of source from multicast data packet in register.
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 22
22
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 23
23
PIM Query
PIM Query
PIM-DM Router 1
171.68.37.1
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 24
24
wan-gw8>show
wan-gw8>show ipip pim
pim neighbor
neighbor
PIM
PIM Neighbor
Neighbor Table
Table
Neighbor
Neighbor Address
Address Interface
Interface Uptime
Uptime Expires
Expires Mode
Mode
171.68.0.70
171.68.0.70 FastEthernet0
FastEthernet0 2w1d
2w1d 00:01:24
00:01:24 Dense
Dense
171.68.0.91
171.68.0.91 FastEthernet0
FastEthernet0 2w6d
2w6d 00:01:01
00:01:01 Dense
Dense (DR)
(DR)
171.68.0.82
171.68.0.82 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:14
00:01:14 Dense
Dense
171.68.0.86
171.68.0.86 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:13
00:01:13 Dense
Dense
171.68.0.80
171.68.0.80 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:02
00:01:02 Dense
Dense
171.68.28.70
171.68.28.70 Serial2.31
Serial2.31 22:47:11
22:47:11 00:01:16
00:01:16 Dense
Dense
171.68.28.50
171.68.28.50 Serial2.33
Serial2.33 22:47:22
22:47:22 00:01:08
00:01:08 Dense
Dense
171.68.27.74
171.68.27.74 Serial2.36
Serial2.36 22:47:07
22:47:07 00:01:21
00:01:21 Dense
Dense
171.68.28.170
171.68.28.170 Serial0.70
Serial0.70 1d04h
1d04h 00:01:06
00:01:06 Dense
Dense
171.68.27.2
171.68.27.2 Serial1.51
Serial1.51 1w4d
1w4d 00:01:25
00:01:25 Dense
Dense
171.68.28.110
171.68.28.110 Serial3.56
Serial3.56 1d04h
1d04h 00:01:20
00:01:20 Dense
Dense
171.68.28.58
171.68.28.58 Serial3.102
Serial3.102 12:53:25
12:53:25 00:01:03
00:01:03 Dense
Dense
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 25
25
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 26
26
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.)
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 28
28
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 30
30
D = Dense Mode
C = Directly Connected Host
L = Local (Router is member)
P = Pruned (All intfcs in OIL = Prune)
T = 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
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 32
32
S3
rtr-a
S0
rtr-b
E1
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.
(*,
(*, 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,
Serial1, Forward/Dense, 00:00:10/00:00:00
Forward/Dense, 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
(*,
(*, 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,
Serial1, Forward/Dense, 00:00:10/00:00:00
Forward/Dense, 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.
(*,
(*, 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
Source
RPF Interface
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 37
37
Interface Fails
X
Source
RPF Interface
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 38
38
X
Source
But wait . . .
This Router still
hasnt converged yet
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 39
39
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 40
40
S0
Initial Flooding State
rtr-b
in rtr-a
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,
Serial1, Forward/Dense, 00:00:10/00:00:00
Forward/Dense, 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
X
2 Prune
S0
rtr-b
E1
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-bs (S, G) entry (shown
in the previous slide) by the Null OIL and the corresponding P flag being set.
As a result of the above, rtr-b sends an (S, G) Prune message to rtr-a to
shutoff the flow of unwanted traffic.
Step 3
rtr-a responds by pruning interface Serial3. (This is reflected in the (S, G) state
shown in the next slide.)
State in rtr-a S0
after Pruning 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-b S0
before/after Pruning 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
1 E0 E0 Join 3
Prune
rtr-b 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
Source X X
X X
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 46
46
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 47
47
E0 E0
rtr-b rtr-c
E1 E1
Beginning State
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 48
48
E0 E0
(*,
(*, 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
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
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
E0 E0
2 PIM Graft
rtr-b rtr-c
E1 E1
IGMP Join 1
Rcvr A
E0 E0
(*,
(*, 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
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,
Ethernet1, Forward/Dense, 00:04:10/00:00:00
Forward/Dense, 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: CCT
T
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
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
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 56
56
S0 S0
A B
E0 1 E0
.1 .2
192.168.1.0/24
C Receiver
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
Loser Winner
S0 S0
2 A B 2
Assert Pruned Assert
E0 E0
<distance, metric>
X
.1 .2 <distance, metric>
192.168.1.0/24
C Receiver
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.
Loser Winner
S0 S0
A B 3
E0 E0 Prune
X
.1 .2
192.168.1.0/24
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.
Loser Winner
S0 S0
A B
E0 E0 Pruned 6
X
.1 .2
192.168.1.0/24
5
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 Bs Ethernet interface will timeout after 3 minutes
just as if it had received an (S, G) prune on this interface. This means that
traffic will start to flow via this interface after 3 minutes which will trigger
Router A to start the Assert process all over again.
S0 S0
A B
.1 E0 E0 .2
198.92.2.0/24
Routing Protocol Boundary
State in Router C
before Assert C
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 61
61
RPF Neighbor
198.92.2.0/24
Routing Protocol Boundary
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 62
62
RPF Neighbor
X
198.92.2.0/24
Routing Protocol Boundary
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 63
63
RPF Neighbor
198.92.2.0/24
Routing Protocol Boundary
State in Router C
after Assert C Assert Winner
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 64
64
Receiver Receiver
Multicast Packets
Source
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 65
65
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
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
Receiver Receiver
XWinner
Multicast Packets
Source
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 68
68
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 69
69
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 70
70
A B
C D F
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 71
71
A B
C D F
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 72
72
A B
G
Prune
C D F
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 73
73
A B
C D F
Asserts
H
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 74
74
A B
C D F
Prune H
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 75
75
Es Prune is Ignored
A B
C D F
Prune H
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 76
76
Gs Prune is Overridden
A B Prune
C D F Join Override
E I
Receiver 1 Receiver 2
Module3. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 11:41 AM 77
77
A B
C D F
Graft 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 78
78
A B
C D F
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
ip multicast-
multicast- routing
S0 interface Ethernet 0
ip address 1.1.1.1 255.255.0.0
ip pim dense
dense-
- mode
E1
E0
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
(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.)
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 1
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 2
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 3
Show commands
Debug commands
Other useful commands
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 4
R4#show
R4#show ip
ip igmp
igmp group
group
IGMP
IGMP Connected
Connected Group
Group Membership
Membership
Group Address
Group Address Interface
Interface Uptime
Uptime Expires
Expires Last
Last RReporter
eporter
224.1.1.1
224.1.1.1 Ethernet1
Ethernet1 3d16h
3d16h 00:01:59
00:01:59 172.16
172.16.7.2
.7.2
224.0.1.40
224.0.1.40 Ethernet0
Ethernet0 4d15h
4d15h never
never 172.16 .6.2
172.16 .6.2
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 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
R4#show
R4#show ip
ip igmp
igmp interface
interface
Ethernet1
Ethernet1 isis up,
up, line
line protocol
protocol is is up
up
Internet
Internet address is
address 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
Current IGMP version is 2is 2
CGMP
CGMP is
is disabled
disabled onon interface
interface
IGMP
IGMP query
query interval
interval isis 60
60 seconds
seconds
IGMP
IGMP querier timeout is
querier timeout 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 isis not
not set
set
Multicast
Multicast routing
routing isis 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 isis 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
R6#show
R6#show ip
ip pim
pim neighbor
neighbor
PIM
PIM Neighbor
Neighbor Table
Table
Neighbor
Neighbor Address Interface
Address Interface Uptime
Uptime Expires
Expires Mode
Mode
172.16.10.2
172.16.10.2 Serial0
Serial0 4d15h
4d15h 00:01:19
00:01:19 Dense
Dense
172.16.11.2
172.16.11.2 Serial1
Serial1 4d15h
4d15h 00:01:00
00:01:00 Dense
Dense
172.16.9.1
172.16.9.1 Ethernet0
Ethernet0 4d15h
4d15h 00:01:00
00:01:00 Dense
Dense
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 7
R6#show
R6#show ip
ip pim
pim interface
interface
Address
Address Interface
Interface Mode
Mode Nbr
Nbr Query
Query DR
DR
Count
Count Intvl
Intvl
172.16.10.1
172.16.10.1 Serial0
Serial0 Dense
Dense 11 3030 0.
0.0.0.0
0.0.0
172.16.11.1
172.16.11.1 Serial1
Serial1 Dense
Dense 11 3030 0.
0.0.0.0
0.0.0
172.16.9.2
172.16.9.2 Ethernet0
Ethernet0 Dense
Dense 11 3030 17
172.16.9.2
2.16.9.2
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 8
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: R3R3 (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
RPF interface: Ethernet0
interface: 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
The second example is the RPF information for the source of the
multicast group
R4#show
R4#show ip
ip route
route
Gateway
Gateway of
of last
last resort
resort is
is not
not set
set
172.16.0.0/24
172.16.0.0/24 is
is subnetted
subnetted,, 77 subnets
subnets
DD 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
DD 172.16.3.0
172.16.3.0 [90/2354611] via 172.16.6.1,
[90/2354611] via 172.16.6.1, 4d15h,
4d15h, Ethernet0
Ethernet0
DD 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
DD 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
CC 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
DD 172.16.10.0
172.16.10.0 [90/2281542]
[90/2281542] viavia 172.16.6.1,
172.16.6.1, 4d15h,
4d15h, Ethernet
Ethernet00
DD 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
DD 192.169.1.0
192.169.1.0 [90/2349056]
[90/2349056] viavia 172.16.6.1,
172.16.6.1, 3d15h,
3d15h, Ethernet
Ethernet00
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 10
10
This slide for reference only for following slides - this table taken from
R4
Recall that multicast forwarding decisions are made based on the
unicast routing table - make sure you understand the UNICAST
topology and stability before looking at MULTICAST issues
R6#show
R6#show ipip 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
barrnet
barrnet-gw>show
-gw>show ipip mroute
mroute
IP
IP Multicast
Multicast Routing
Routing Table
Table
Flags:
Flags: D - Dense, S -- Sparse,
D - Dense, S Sparse, CC -- Connected,
Connected, LL -- Local,
Local, PP -- Pruned
Pruned
RR -- RP-bit
RP-bit set, FF -- Register
set, 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, RPFRPF 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), 05:35:08/00:02:58,
239.100.111.224), 05:35:08/00:02:58, RP RP 171.69.10.13,
171.69.10.13, flags:
flags: DPDP
Incoming
Incoming interface: Null, RPF nbr
interface: Null, RPF nbr 0.0.0.0
0.0.0.0
Outgoing interface list:
Outgoing interface list: NullNull
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 12
12
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:
Rate: 11 pps/30 kbps(1sec), 30
11 pps/30 kbps(1sec), 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:
Rate: 24 pps/69 kbps(1sec), 72 kbps(last 2 secs), 70
24 pps/69 kbps(1sec), 72 kbps(last 2 secs), 70 kbps(life
kbps(life avg
avg))
Group:
Group: 224.2.180.115,
224.2.180.115, ANLANL 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
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:
Source: 171.69.10.13/32, Forwarding: 0/0/0/0, Other: 0/0/0 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
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
Serial0 MAC
MAC Header: 0F000800
Header: 0F000800
Serial1
Serial1 MAC Header: 0F000800
MAC Header: 0F000800
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 15
15
sjck-rp1>show
sjck-rp1>show ipip pim
pim rp
rp mapping
mapping
PIM
PIM Group
Group-to-RP
-to-RP Mappings
Mappings
This
This system is an RP (Auto-RP)
system is an RP (Auto -RP)
This
This system
system is
is an
an RP-mapping
RP-mapping agent
agent (Loopback1)
(Loopback1)
Group(s)
Group(s) 224.0.0.0/4
224.0.0.0/4
RP
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
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
*cisco 500k San Jose
500k San Jose && RTP
RTP
*cisco 500k SJ and
*cisco 500k SJ and RTPRTP
..
..
..
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 17
17
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 18
18
Show commands
Debug commands
Other useful commands
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 19
19
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 v2v2 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:
IGMP: Received v2 Query from 172.16.6.1 (Ethernet0)
Received v2 Query from 172.16.6.1 (Ethernet0)
IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth
IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth ernet0 ernet0
IGMP:
IGMP: Send
Send v2
v2 Report
Report for
for 224.0.1.40
224.0.1.40 onon Ethernet0
Ethernet0
IGMP:
IGMP: Received
Received v2v2 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:
IGMP: Received v2 Report from 172.16.6.1 (Ethernet0)
Received v2 Report from 172.16.6.1 (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
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: IP tos=0x0, len =100, id=0x175, ttl=254,
IP tos=0x0, len =100, id=0x175, ttl=254, prot=1
prot=1
IP:
IP: s=172.16.12.2 (Ethernet1) d=224.1.1.1 len 114,
s=172.16.12.2 (Ethernet1) d=224.1.1.1 len 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
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
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:
PIM: Received Router-Query on
Received Router-Query 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
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:
PIM: Send periodic Join/Prune to RP via 172.16.6.1
Send periodic Join/Prune to RP via 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.
R1#
R1#
PIM:
PIM: Received
Received Join/Prune
Join/Prune onon 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) RPRP 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 onon 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 onon Serial0
Serial0
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 25
25
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 toto 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 RPRP-Reachable
-Reachable on
on Serial1
Serial1 from
from 172.16.8.1
172.16.8.1
PIM:
PIM: Received
Received RPRP-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:
PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, 224.1.1.1),
Add Ethernet0/172.16.9.1 to (172.16.12.2/32, 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
PIM: No sources in join or prune listlist
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 toto (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
R1#
R1# PIM:
PIM: Received
Received Register
Register onon 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:
PIM: Send Join on Ethernet1 to 172.16.8.2 for (172.16.12.2/32, 2224.1.1.1)
Send Join on Ethernet1 to 172.16.8.2 for (172.16.12.2/32, 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
PIM: Join -list: (172.16.12.2/32, 224.1.1.1), S-bit set 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 onon 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) RPRP 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:
PIM: Send periodic Join/Prune to 172.16.8.2 (Serial0)
Send periodic Join/Prune to 172.16.8.2 (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 toto 172.16.9.2
172.16.9.2 forfor 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.
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.
Show commands
Debug commands
Other useful commands
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 28
28
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 29
29
src dest
First-hop mt Last-hop
rac
Router e Router
res st
po ue
ns
e req
e
rac
Multicast mt
Dist. Tree
Mtrace Packet
Unix Workstation
Note: Mtracepackets use special
or
IGMP packets with IGMP Type Cisco Router
codes of 0x1E and 0x1F.
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 30
30
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 33
33
Shows:
Multicast path from source to receiver.
Similar to unicast trace command
Trace path between any two points in network
TTL Thresholds & Delay shown at each node
Troubleshooting Usage:
Find where multicast traffic flow stops.
Focus on router where flow stops
Verify path multicast traffic is following.
Identify sub-optimal paths.
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 34
34
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) PIMPIM 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:
Multicast path in pseudo graphic format.
Trace path between any two points in network
Drops/Duplicates shown at each node
TTLs & Delay shown at each node
Troubleshooting Usage:
Locate congestion point in the flow.
Focus on router with high drop/duplicate count
Duplicates indicated as negative drops
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 36
36
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 38
38
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
ISP-251#ping
ISP-251#ping 224.1.1.1
224.1.1.1
Type
Type escape
escape sequence
sequence toto 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
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 41
41
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 206416.908
206416.908 (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
7302/113
7302/113 206417.172
206417.172 (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
6CB2/114
6CB2/114 206417.412
206417.412 ((wayback .uoregon.edu ) 128.223.156.117 224.2.231.173
wayback .uoregon.edu ) 128.223.156.117 224.2.231.173
D786/117
D786/117 206417.868
206417.868 (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
E2E9/123
E2E9/123 206418.488
206418.488 ((dino-ss20.cisco.com)
dino-ss20.cisco.com) 171.69.58.81
171.69.58.81 224.2.231.173
224.2.231.173
1CA7/127
1CA7/127 206418.544
206418.544 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
1CAA/127
1CAA/127 206418.584
206418.584 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
1CAC/127
1CAC/127 206418.624
206418.624 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
1CAF/127
1CAF/127 206418.664
206418.664 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
1CB0/127
1CB0/127 206418.704
206418.704 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
1CB2/127
1CB2/127 206418.744
206418.744 ((dino-ss2.cisco.com)
dino-ss2.cisco.com) 171.69.129.220
171.69.129.220 224.2.231.173
224.2.231.173
2BBB/114
2BBB/114 206418.840
206418.840 ((crevenia.parc.xerox
crevenia.parc.xerox.com)
.com) 13.2.116.11
13.2.116.11 224.2.231.173
224.2.231.173
3D1D/123
3D1D/123 206419.380
206419.380 ((dalvarez-ss20.cisco.com)
dalvarez-ss20.cisco.com) 171.69.60.189
171.69.60.189 224.2.231.173
224.2.231.173
2BC0/114
2BC0/114 206419.672
206419.672 ((crevenia.parc.xerox
crevenia.parc.xerox.com)
.com) 13.2.116.11
13.2.116.11 224.2.231.173
224.2.231.173
7303/113
7303/113 206419.888
206419.888 (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
7304/113
7304/113 206420.140
206420.140 (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
2C7E/123
2C7E/123 206420.360
206420.360 ((lwei-ss20.cisco.com)
lwei-ss20.cisco.com) 171.69.58.88
171.69.58.88 224.2.231.173
224.2.231.173
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 42
42
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
Troubleshooting Table
Source Network Receivers
Signaling NA ? ?
Packet Flow ? ? ?
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
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 45
45
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 46
46
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 47
47
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 48
48
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 49
49
mstat command
ping command
show ip mroute count
show ip mroute active
debug ip mpacket
Be Careful with this one!
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 50
50
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 51
51
Module4. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 1:55 PM 52
52
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 2
2
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 3
3
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 5
5
RP
Receiver
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 6
6
RP
Source
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 7
7
RP
Source
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 8
8
RP
Source
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 9
9
RP
Source
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 10
10
RP
Source
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 11
11
RP
Source
Module5.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 12
12
RP
Source
Module5.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 13
13
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 14
14
PIM Hello
PIM Hello
PIM Router 1
171.68.37.1
wan-gw8>show
wan-gw8>show ip
ip pim
pim neighbor
neighbor
PIM
PIM Neighbor
Neighbor Table
Table
Neighbor
Neighbor Address
Address Interface
Interface Uptime
Uptime Expires
Expires Mode
Mode
171.68.0.70
171.68.0.70 FastEthernet0
FastEthernet0 2w1d
2w1d 00:01:24
00:01:24 Sparse
Sparse
171.68.0.91
171.68.0.91 FastEthernet0
FastEthernet0 2w6d
2w6d 00:01:01
00:01:01 Sparse
Sparse (DR)
(DR)
171.68.0.82
171.68.0.82 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:14
00:01:14 Sparse
Sparse
171.68.0.86
171.68.0.86 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:13
00:01:13 Sparse
Sparse
171.68.0.80
171.68.0.80 FastEthernet0
FastEthernet0 7w0d
7w0d 00:01:02
00:01:02 Sparse
Sparse
171.68.28.70
171.68.28.70 Serial2.31
Serial2.31 22:47:11
22:47:11 00:01:16
00:01:16 Sparse
Sparse
171.68.28.50
171.68.28.50 Serial2.33
Serial2.33 22:47:22
22:47:22 00:01:08
00:01:08 Sparse
Sparse
171.68.27.74
171.68.27.74 Serial2.36
Serial2.36 22:47:07
22:47:07 00:01:21
00:01:21 Sparse
Sparse
171.68.28.170
171.68.28.170 Serial0.70
Serial0.70 1d04h
1d04h 00:01:06
00:01:06 Sparse
Sparse
171.68.27.2
171.68.27.2 Serial1.51
Serial1.51 1w4d
1w4d 00:01:25
00:01:25 Sparse
Sparse
171.68.28.110
171.68.28.110 Serial3.56
Serial3.56 1d04h
1d04h 00:01:20
00:01:20 Sparse
Sparse
171.68.28.58
171.68.28.58 Serial3.102
Serial3.102 12:53:25
12:53:25 00:01:03
00:01:03 Sparse
Sparse
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 16
16
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 17
17
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.)
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 19
19
(S,G) creation
By receipt of (S,G) Join or Prune or
By Register process
Parent (*,G) created (if doesnt exist)
(S,G) reflects forwarding of S to G
IIF = RPF Interface normally toward source
RPF toward RP if RP-bit set
OIL = Initially, copy of (*,G) OIL minus IIF
(S,G) deletion
By normal (S,G) entry timeout
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 21
21
S = Sparse Mode
C = Directly Connected Host
L = Local (Router is member)
P = Pruned (All intfcs in OIL = Prune)
T = 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
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
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.)
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.)
PIM-SM Flags
M Flag (MSDP Created)
This flag only appears on (S, G) entries and only on the router that is the
active RP for group G.
The flag indicates that the RP has learned of this particular source via an
MSDP Source Active message. (MSDP is addressed in more detail in
another module.)
A Flag (Advertise Flag)
This flag only appears on (S, G) entries and only on the router that is the
active RP for group G.
The A flag indicates that this source is in the local PIM-SM domain and
that it is a candidate for being announced to RPs in other networks via
MSDP Source Active messages.
A source is considered to be in the local domain if an (S, G) Register
message was received for this source or the source is directly connected to
the RP or the (S, G) traffic was received on a Dense mode interface that has
been designated as a dense mode boundary interface.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 29
29
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 30
30
S0 rtr-a
10.1.4.2
E0
Shared Tree 10.1.2.1
10.1.2.2
E0
E1
1 IGMP Join rtr-b
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 31
31
S0 rtr-a
10.1.4.2
E0
Shared Tree 10.1.2.1
10.1.2.2
E0
E1
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,
Ethernet1, Forward/Sparse,
Forward/Sparse,
Forward/Sparse, 00:00:05/00:02:54
00:00:05/00:02:54
00:00:05/00:02:54
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 32
32
S0 rtr-a
10.1.4.2
E0
Shared Tree 10.1.2.1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 33
33
S0 rtr-a
10.1.4.2
E0
Shared Tree 10.1.2.1
10.1.2.2
E0
E1
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, Forward/Sparse,
Ethernet0, Forward/Sparse, 00:00:05/00:02:54
00:00:05/00:02:54
00:00:05/00:02:54
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 34
34
10.1.2.2
E0
E1
rtr-b
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 36
36
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 37
37
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 38
38
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 39
39
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.
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
Shared Tree
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 40
40
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 41
41
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
Shared Tree
No such group.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 42
42
(171.68.37.121, 224.1.1.1)
Mcast Packets
1 RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
Shared Tree
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 43
43
(171.68.37.121, 224.1.1.1) 2
Register Msgs
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
Shared Tree
(*,
(*, 224.1.1.1),
224.1.1.1), 00:00:03/00:02:56,
00:00:03/00:02:56, RPRP 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:00:03/00:02:56, flags: FPT
00:00:03/00:02:56, flags: FPT
FPT
Incoming
Incoming interface:
interface: Ethernet0,
Ethernet0, RPF
RPF nbr 0.0.0.0, Registering
nbr 0.0.0.0,
Outgoing
Outgoing interface
interface list:
list: Null
Null
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
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
Source E0 S0 S0 S1
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 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
Source E0 S0 S0 S1
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
171.68.28.190
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: 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:
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
Source E0 S0 S0 S1
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 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, RPRP 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 48
48
Source E0 S0 S0 S1
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
7 Register -Stop Mcast Traffic
Shared Tree
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 49
49
(171.68.37.121, 224.1.1.1)
Mcast Packets
8 RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 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, RPRP 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
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 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: 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 51
51
(171.68.37.121, 224.1.1.1)
Mcast Packets
171.68.28.139
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 53
53
In the following examples we will consider the Register process for the cases
when:
Receivers join group G first;
The Source Registers first.
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
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.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 54
54
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
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.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 55
55
RP
E0 S0 S0 S1 S3
S0 S1 rtr-c
rtr-a rtr-b
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 56
56
(171.68.37.121, 224.1.1.1)
Mcast Packets
1 RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 57
57
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*,
(*, 224.1.1.1),
224.1.1.1), 00:00:03/00:02:56,
00:00:03/00:02:56, RPRP 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:00:03/00:02:56, flags: FPT
00:00:03/00:02:56, flags: FPT
FPT
Incoming
Incoming interface:
interface: Ethernet0,
Ethernet0, RPF
RPF nbr 0.0.0.0, Registering
nbr 0.0.0.0,
Outgoing
Outgoing interface
interface list:
list: Null
Null
Source E0 S0 S0 S1 S3 3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 59
59
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
Register -Stop 4
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
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
5
5 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
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.
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*,
(*, 224.1.1.1),
224.1.1.1), 00:01:28/00:01:32,
00:01:28/00:01:32, RPRP 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 62
62
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
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.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 63
63
(171.68.37.121, 224.1.1.1)
Mcast Packets
171.68.28.139
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*,
(*, 224.1.1.1),
224.1.1.1), 00:01:15/00:01:45,
00:01:15/00:01:45, RPRP 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 64
64
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, G) Join 6
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 65
65
(171.68.37.121, 224.1.1.1)
Mcast Packets 7
(S, G) Join RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(171.68.37.121, 224.1.1.1)
Mcast Packets 8
(S, G) Join RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
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:
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
(171.68.37.121, 224.1.1.1)
Mcast Packets
9 RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
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, RPRP 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
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
171.68.28.190 (*, 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, RPRP 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 69
69
(171.68.37.121, 224.1.1.1)
Mcast Packets
171.68.28.139
RP
Source E0 S0 S0 S1 S3
171.68.37.121 S0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
Mcast Traffic
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 70
70
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 71
71
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.
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 S1 rtr-c
rtr-a rtr-b
(*, 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, RPRP 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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 72
72
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
Mcast Traffic
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 73
73
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 E0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
1 IGMP Join Mcast Traffic
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 74
74
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 E0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
Mcast Traffic
Rcvr A
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 E0
2 S1 rtr-c
rtr-a rtr-b
(*, G) Join
(*, 224.1.1.1)
Mcast Traffic
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 76
76
(171.68.37.121, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 E0 S1 rtr-c
rtr-a rtr-b
(*, 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, 224.1.1.1)
Mcast Packets
RP
Source
S0 S1 S3
171.68.37.121 E0 S1 rtr-c
rtr-a rtr-b
(*, 224.1.1.1)
3 Mcast Traffic
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 79
79
SPT Thresholds
In PIM Sparse mode, SPT Thresholds may be configured to control when to
switch to the Shortest-Path Tree (SPT).
SPT Thresholds are specified in Kbps and can be used with Access List to
specify to which Group(s) the Threshold applies.
The default SPT-Threshold is 0Kbps. This means that any and all sources are
immediately switched to the Shortest-Path Tree.
If an SPT-Threshold of Infinity is specified for a group, the sources will not be
switched to the Shortest-Path Tree (SPT) and will remain on the Shared Tree.
Exceeding the Threshold
When the Groups SPT-Threshold is exceed in a last-hop router, the next
received packet for the group will cause an (S, G) Join to be sent toward the
source of the packet. This builds a Shortest-Path Tree from the source S to
the last-hop router.
PROS
By switching to the Shortest-Path Tree (SPT), the most optimal (usually) path is
used to deliver the multicast traffic. Depending on the location of the source in
relation to the RP, this switch to the SPT can reduce network latency
substantially.
CONS
In networks with large numbers of senders (remember most multicast
applications such as IP/TV Client, send RTCP multicast packets in the
background and are therefore senders), an increased amount of state must be
kept in the routers. In some cases, an Infinity threshold may be used to force
certain groups to remain on the Shared Tree when latency is not an issue.
SPT-Switchover Mechanism
Once
Once each
each second
second
Compute
Compute new new (*,
(*, G)
G) traffic
traffic rate
rate
IfIf threshold
threshold exceeded,
exceeded, setset 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)
Join
Join SPT
SPT for for (S
(Sii ,, G)
G)
Mark
Mark (S
(Sii ,, G)
G) entry
entry with with J
J flag
flag
Clear
Clear J
J flag
flag in
in (*,G)
(*,G)
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 81
81
SPT-Threshold Myth
This is a frequently misunderstood mechanism. Many people think that the the
traffic rates of the sources in the group are monitored and compared against the
SPT-Threshold. THIS IS NOT THE CASE. Instead, the total aggregate rate of
Group traffic flowing down the Shared Tree (RPT) is calculated once per
second. If this total aggregate rate is exceed, then the next Group packet
received causes that source to be switched to the Shortest-Path Tree (SPT).
SPT-Switchover Mechanism
Once each second, the aggregate (*, G) traffic rate is computed and checked
against the SPT-Threshold. If the aggregate rate of all group traffic flowing
down the Shared Tree (RPT) exceeds the threshold, then the J flag is set in
the (*, G) entry.
As each multicast packet is received on the Shared Tree, the J bit is checked
in the (*, G) entry.
If the J flag is set, a new (S, G) entry is created for the source of the
packet.
An (S, G) Join is sent towards the source in order to join the SPT.
The J flag is set in the (S, G) entry to denote that this entry was created as
a result of the SPT-Threshold switchover.
The J flag in the (*, G) is reset. (It will be set in one second if the
aggregate rate on the Shared Tree is still over the SPT-Threshold.)
This mechanism can sometimes result in low rate sources being switched to the
SPT erroneously. However, the RPT-switchback mechanism will correct this
situation and eventually only the high rate sources will be received via SPTs
while low rate sources will remain on the Shared Tree.
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 82
82
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 83
83
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 84
84
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
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
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 85
85
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2 1 Group G rate > Threshold
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ 2
Incoming interface: Ethernet0, RPF nbr 10.1.2.1,
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:01:43/00:02:11
1 Group G rate exceeds SPT Threshold at rtr-b;
2 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
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0 3
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ 4
Incoming interface: Ethernet0, RPF nbr 10.1.2.1,
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:01:43/00:02:11
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2 5 (Si,G) Join
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 89
89
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
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
S2 6 (Si,G) Join
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 91
91
S2 7 (S ,G) Traffic
S0 i
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 92
92
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
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
S2 9 S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 95
95
10 S2
S0
10.1.4.2
E010.1.2.1
S0
10.1.2.2
rtr-d E0
(Si, G) Traffic Flow
E1
E0 rtr-b Shared (RPT) Tree
Rcvr A SPT Tree
Rcvr B
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 96
96
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 97
97
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 98
98
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 99
99
SM Pruning
Locally connected host sends an IGMP Leave (or IGMP state times out in the
router) for group G.
The interface is removed from the (*, G) and all (S, G) entries in the Multicast
Routing Table.
If the (*, G) Outgoing Interface list is now Null, then send a (*, G) Prune up
the Shared Tree (RPT) towards the RP.
Any remaining (S, G) entries are allowed to timeout and be deleted from the
Multicast Routing Table.
When the routers up the Shared Tree receive the (*, G) Prune, they remove the
interface on which the Prune was received from their (*, G) Outgoing interface
list.
If as a result of removing the interface the (*, G) Outgoing Interface list
becomes Null, then forward a (*, G) Prune up the Shared Tree (RP T)
towards the RP.
Any remaining (S, G) entries are allowed to timeout and be deleted from the
Multicast Routing Table.
S0 rtr-a
(Si, G) Traffic Flow 10.1.4.2
E0
10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 100
100
S0 rtr-a
(Si, G) Traffic Flow 10.1.4.2
E0
10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
Rcvr A
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 101
101
S0 rtr-a
(Si, G) Traffic Flow 10.1.4.2
E0
10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0 3 (*,G) Prune
1 IGMP Leave E1
rtr-b
X
Rcvr A
2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 102
102
(*,G) Prune
X S0 rtr-a
(Si, G) Traffic Flow 5 10.1.4.2
E0
10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
X 4
E0
E1
rtr-b
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 103
103
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
5) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
6) This pruning continues back toward the RP or until a router is reached whose
(*, G) Outgoing interface list doesnt go to Null as a result of the Prune.
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
Rcvr A
(*,
(*, 224.1.1.1),
224.1.1.1), 00:01:43/00:02:59,
00:01:43/00:02:59, RP
RP 10.1.5.1,
10.1.5.1, flags:
flags: SC
SC
Incoming
Incoming interface:
interface: Ethernet0,
Ethernet0, RPF
RPF nbr
nbr 10.1.2.1,
10.1.2.1,
Outgoing
Outgoing interface
interface list:
list:
Ethernet1,
Ethernet1, Forward/Sparse,
Forward/Sparse, 00:01:43/00:02:11
00:01:43/00:02:11
(171.68.37.121/32,
(171.68.37.121/32, 224.1.1.1),
224.1.1.1), 00:01:05/00:01:55,
00:01:05/00:01:55, flags:
flags: CJT
CJT
Incoming
Incoming interface:
interface: Ethernet0,
Ethernet0, RPF
RPF nbr
nbr 10.1.2.1
10.1.2.1
Outgoing
Outgoing interface
interface list:
list:
Ethernet1,
Ethernet1, Forward/Sparse,
Forward/Sparse, 00:01:05/00:02:55
00:01:05/00:02:55
Module5. ppt
State in rtr-b before Pruning
1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 104
104
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
Rcvr A
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0 3 (*,G) Prune
1 IGMP Leave E1
rtr-b
X
Rcvr A
2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 106
106
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
X
SPT Tree 10.1.2.2 Periodic
E0 4
(S, G) Join
E1
rtr-b
X
Rcvr A
To Source Si
S1
To RP (10.1.5.1)
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 108
108
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si,
G) state eventually times out. This causes a (Si, G) Prune to be sent up the
Shortest-Path Tree (SPT) towards the source Si.
8) Traffic stops flowing down the Shortest-Path Tree (SPT).
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si,
G) state eventually times out. This causes a (Si, G) Prune to be sent up the
Shortest-Path Tree (SPT) towards the source Si.
8) Traffic stops flowing down the Shortest-Path Tree (SPT).
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
(*,
(*, 224.1.1.1),
224.1.1.1), 00:02:32/00:02:59,
00:02:32/00:02:59, RP
RP 10.1.5.1,
10.1.5.1, flags:
flags: SP
SP
Incoming
Incoming interface:
interface: Serial0,
Serial0, RPF
RPF nbr
nbr 10.1.4.1,
10.1.4.1,
Outgoing
Outgoing interface list:
interface list:
(171.68.37.121/32,
(171.68.37.121/32, 224.1.1.1),
224.1.1.1), 00:01:56/00:00:53,
00:01:56/00:00:53, flags:
flags: PT
PT
Incoming
Incoming interface:
interface: Serial1,
Serial1, RPF
RPF nbr
nbr 10.1.9.2
10.1.9.2
Outgoing
Outgoing interface
interface list:
list:
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si,
G) state eventually times out. This causes a (Si, G) Prune to be sent up the
Shortest-Path Tree (SPT) towards the source Si.
8) Traffic stops flowing down the Shortest-Path Tree (SPT).
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 111
111
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si,
G) state eventually times out. This causes a (Si, G) Prune to be sent up the
Shortest-Path Tree (SPT) towards the source Si.
8) Traffic stops flowing down the Shortest-Path Tree (SPT).
9
To Source Si
S1
To RP (10.1.5.1)
S0 rtr-a
10.1.4.2
(Si, G) Traffic Flow E0 10.1.2.1
Shared Tree
SPT Tree 10.1.2.2
E0
E1
rtr-b
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 112
112
(Note: rtr-a delayed Pruning E0 from the (*, G) entry for 3 seconds since this is
a Multi-Access network and it needed to wait for a possible overriding Join from
another PIM neighbor. Since none was received, the interface was pruned.)
6) Because the (*, G) Outgoing interface list is now Null, a (*, G) Prune is
forwarded on up the Shared Tree (RPT) via S0 toward the RP.
7) Because rtr-a is no longer receiving (Si, G) Join messages from rtr-b, the (Si,
G) state eventually times out. This causes a (Si, G) Prune to be sent up the
Shortest-Path Tree (SPT) towards the source Si.
8) Traffic stops flowing down the Shortest-Path Tree (SPT).
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 113
113
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 114
114
A B RP D
C E
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 115
115
A B RP D
Join
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 116
116
A B RP D
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 117
117
Register
A B RP D
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 118
118
Join Join
A B RP D
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 119
119
Register-Stop
A B RP D
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 120
120
A B RP D
(S, G) Join
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 121
121
(S, G) Prune
A B RP D
(S, G) RP Bit Prune
C E
Receiver 1
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 122
122
(Note: The RP-bit indicates to up-stream routers that this prune should flow up
the Shared Tree (RPT) to the RP.)
The RP receives the (S, G)RP-bit Prune and removes the interface (towards
C) from the (S, G) oilist. This stops the flow of Source 1 traffic down the
Shared Tree to C.
The RPs (S, G) oilist is now Null (I.e. there are no other branches on the
Shared Tree that want Source 1 traffic)and therefore no long needs Source 1
traffic. The RP responds by sending (S, G) Prunes towards Source 1. This
stops the flow of Source 1 traffic to the RP.
A B RP D
(*, G) Join
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 123
123
A B RP D
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 124
124
(Note: Since C already had (*, G) state, it is not necessary to send a (*, G) join
toward the RP again.)
Group G traffic now begins flowing through C and E to Receiver 2.
Register
A B D Source 2
RP
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 125
125
RP Sends Joins to D
Register
A B Join D Source 2
RP
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 126
126
Register-Stop
A B D Source 2
RP
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 127
127
A B D Source 2
RP
C E
Receiver 1 Receiver 2
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 128
128
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 130
130
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 131
131
ip pim sparse-dense-mode
on an interface. This results in the interface always matching the Group mode.
Sparse/Dense mode should normally be used if running Auto-RP. This allows
the two Auto-RP groups (224.0.1.39 and 224.0.1.40) to operate in Dense mode.
Once the routers in the network learn (via Auto-RP) the address of the elected
RP, they will operate all other groups in Sparse mode. (By default, Auto-RP
learned Group-to-RP ranges never include the Auto-RP groups.)
Sparse/Dense mode can be also be used if pure Sparse mode or pure Dense
mode operation is desired by either configuring or not configuring an RP address
on each router, respectively.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 133
133
Common Misconception
Interface Mode controls Group Mode.
This is a classic error often made by network administrators. They assume that,
If I set all interfaces to ip pim sparse-mode, the router will always operate in
Sparse mode and never fall back into Dense mode. Unfortunately, this is
incorrect.
Group mode is solely controlled by the existence of a valid RP. If a valid RP is
learned/configured for a group range, those groups will operate in sparse mode
and the (*,G) entry will be created with the S flag set. Otherwise, the groups
will operate in Dense mode and the D flag will be set on the (*,G) entry.
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 134
134
Module5.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 135
135
Define an "RP-of-last-resort.
Configure as a Static RP on every router.
Will only be used if all Candidate-RPs fall.
Can be a dummy address.
Recommendation: Use lowest priority C-RP address.
Use ACL to avoid breaking Auto-RP
ip pim rp-address <RP-of-last-resort> 10
access-list 10 deny 224.0.1.39
access-list 10 deny 224.0.1.40
access-list 10 permit any
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 136
136
Avoiding DM Fallback
In order to guarantee that the router will never fall back into dense mode, it is
necessary to guarantee that the router will never loose RP information. This can
be accomplished by defining a static, RP-of-last-resort in each router in the
network. Since automatically learned RPs (Auto-RP or BSR) take precedence
over statically defined RPs, the static entry will only be activated if all learned
RPs timeout and/or fail.
The recommendation is to define the lowest priority Candidate RP as the
RP-of-last-resort by using a static RP definition pointing to this IP address.
This locks the lowest priority RP into the bottom of the failover order. Even if
this router fails (or its information times out), the static entry in each router
will prevent a total loss of RP information.
Special care must be taken if an RP -of-last-resort is defined when using
Auto-RP. By default, a static RP definition that covers the Auto-RP group
range will be interpreted as the RP for the two Auto-RP groups. (Unlike
Auto-RP learned group ranges which have an implied deny for these two
groups so that the two Auto-RP groups will default to using dense mode.)
RP/Mapping Agent
A B
PIM
Sparse Mode
C D
RP/Mapping Agent
Module5. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/10/2001 2:37 PM 137
137
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/13/2001 11:12 AM 1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 2
Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 3
Auto-RP Overview
Auto-RP allows all routers in the network to automatically learn Group-to-RP
mappings.
There are no special configuration steps that must be taken except on the
router(s) that are to function as:
Candidate RPs
Mapping Agents
Multicast is used to distribute Group-to-RP mapping information via two special,
IANA assigned multicast groups.
Cisco-Announce Group - 224.0.1.39
Cisco-Discovery Group - 224.0.1.40
Because multicast is used to distribute this information, a Chicken and Egg
situation can occur if the above groups operate in Sparse mode. (Routers would
have to know a priori what the address of the RP is before they can learn the
address of the RP(s) via Auto-RP messages.) Therefore, it is recommend that
these groups always run in Dense mode so that this information is flooded
throughout the network.
Multiple Candidate RPs may be defined so that in the case of an RP failure, the
other Candidate RP can assume the responsibility of RP.
Auto-RP can be configured to support Administratively Scoped zones. (BSR
cannot!) This can be important when trying to prevent high-rate group traffic
from leaving a campus and consuming too much bandwidth on WAN links.
Candidate RPs
Multicast RP-Announcement messages
Sent to Cisco-Announce (224.0.1.39) group
Sent every rp-announce-interval (default: 60 sec)
RP-Announcements contain:
Group Range (default = 224.0.0.0/4)
Candidates RP address
Holdtime = 3 x <rp-announce-interval>
Configured via global config command
ip pim send-rp-announce <intfc> scope <ttl> [group-list acl]
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 5
Mapping agents
Receive RP-Announcements
Stored in Group-to-RP Mapping Cache with holdtimes
Elects highest C-RP IP address as RP for group range
Multicast RP-Discovery messages
Sent to Cisco-Discovery (224.0.1.40) group
Sent every 60 seconds or when changes detected
RP-Discovery messages contain:
Elected RPs from MAs Group-to-RP Mapping Cache
Configured via global config command
ip pim send-rp-discovery [<interface>] scope <ttl>
Source address of packets set by <interface> (12.0)
If not specified, source address = output interface address
Results in the appearance of multiple MAs. (one/interface)
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 6
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 7
RP/Mapping Agent
A B
PIM
Sparse Mode
C D
RP/Mapping Agent
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8
Announce
Announce
MA MA
A
A B
B
Announce
RP- Announcements multicast to the
Cisco Announce (224.0.1.39) group
Announce
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 9
ry
ery
ove
cov
Disc
Dis
Dis Disc
cov ove
ery MA ry MA
A Dis B Disc
A cov
ery B ove
ry
ery
ry
ove
cov
Disc
Dis
C
C D
D
C-RP C-RP
1.1.1.1 2.2.2.2
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 10
10
C-RP C-RP
1.1.1.1 Rtr -A# show ip pim rp mapping
2.2.2.2
This system is an RP -mapping agent
C D
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 11
11
Auto-RP Up Close
This is the same example that was presented in the previous slides. However,
in this case, we will examine the process in more detail at each step.
Step 1
At time zero, the Group-to-RP mapping caches in the Mapping Agents are
empty since no RP-Announcements have been received.
The output of the show ip pim rp mapping command shows that router A is
a Mapping Agent and that the Group-to-RP mapping cache is empty.
A R
G P=
Ho roup 2.2.2
0/4 ldt
im -R .2
.0.
24.0 e a
An = 1 nge
=2 no 80 = 2
.1 ge ec un sec 24
1.1.1 Ran 80 s nce ce .0.
0.0
= - 1 ou
= /4
RP roup ime Ann
G oldt
H
Rtr -A# show ip pim rp mapping
C-RP This system is an RP -mapping agent C-RP
1.1.1.1 Group(s) 224.0.0.0/4
2.2.2.2
RP 2.2.2.2 (Rtr
(Rtr -
-D),
D), v2v1
Info source: 2.2.2.2 (Rtr -D), via Auto-R P
Uptime: 00:00:03, expires: 00:02:57
C RP 1.1.1.1 (Rtr -C), v2v1 D
Info source: 1.1.1.1 (Rtr -C), via Auto-R P
Uptime: 00:00:11, expires: 00:02:49
Auto-RP Up Close
Step 2
Routers C and D begin sending their RP Announce messages advertising
themselves as a candidate to be RP for all multicast groups. (Note the
group range, the IP address of the C-RP and the holdtime in the message.)
Step 3
The Mapping Agent (router A) receives these RP Announcements and
stores this information in its Group-to-RP mapping cache.
The output of the show ip pim rp mapping command on the Mapping Agent
(router A) now shows both router C and D as candidates for group range
224.0.0.0/4 (i.e. all multicast groups with the exception of the Auto-RP
groups).
The Mapping Agent then elects the C-RP with the highest IP address as the
active RP for the group range.
2.2 ng 80
/4
ov c 0.0
sc se .0.
Di 180 224
e= se
= e=
22 c
ery
g
im - R 2
ve
4.0
e an
.
Ho roup 2.2.2
.0.0
/4
G P=
R
ldt
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 13
13
Auto-RP Up Close
Step 4
The Mapping Agent begins advertising the results of the RP election to the
rest of the network via Auto-RP Discovery messages.
A B
172.16.2.1 172.16.2.2
Rtr -A# show ip pim rp mapping Rtr -B# show ip pim rp mapping
This system is an RP -mapping agent This system is an RP -mapping agent
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 14
14
Auto-RP Up Close
It is critical that all Mapping Agents in the PIM-SM domain have identical
information in their Group-to-RP mapping caches. Note that in our example
network, they do.
If the information in the mapping caches are not identical, it can cause the
routers in the network to flip-flop between two different RPs.
/4
.0.0
ec 4.0
0 s 22
ldt -R .2 y
Ho roup .2.2 over
18 e =
e = ng
G = 2 isc
im a
RP D
X
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 15
15
Auto-RP Up Close
Step 6
Assume that router B is the first MA to send its RP Discovery message
containing its Group-to-RP mapping cache contents.
Step 7
The routers in the network (router X in this example) all receive this RP
Discovery message and install the information in their local Group-to-RP
mapping cache.
The output of the show ip pim rp mapping command shows that router D is
currently selected as the RP for group range 224.0.0.0/4 (i.e. all multicast
groups with the exception of the Auto-RP groups) and that this information
was most recently received from router B.
RP oup e =
Gr ldtim
= 2 - R 180
Ho
between routers
24
.0.0
.0/4
A and B
No performance impact
X
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 16
16
Auto-RP Up Close
Step 8
Next, router A sends an RP Discovery message containing its Group-to-RP
mapping cache contents.
Step 9
The routers in the network (router X in this example) all receive this RP
Discovery message and update the information in their local Group-to-RP
mapping cache. Since both Mapping Agents are sending identical
information, the only thing that will change in the local Group-to-RP mapping
cache is the source of the information.
The output of the show ip pim rp mapping command shows that router D is
still selected as the RP for group range 224.0.0.0/4 (i.e. all multicast groups
with the exception of the Auto-RP groups). However, the data reflects that
this information was most recently received from router A.
The flip-flop of the information source in the routers local Group-to-RP
mapping cache has little or no performance impact on the router.
Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 17
17
BSR Overview
Bootstrap Router (BSR)
A single router is elected as the BSR from a collection of Candidate BSRs.
If the current BSR fails, a new election is triggered.
The election mechanism is pre-emptive based on C-BSR priority.
Candidate RPs (C-RPs)
Send C-RP announcements directly to the BSR via unicast. (Note: C-RPs
learn the IP address of the BSR via periodic BSR messages.)
The BSR stores the complete collection of all received C-RP
announcements in a database called the RP -set.
The BSR periodically sends out BSR messages to all routers in the network to
let them know the BSR is still alive.
BSR messages are flooded hop-by-hop throughout the network.
Multicast to the All-PIM Routers group (224.0.0.13 ) with a TTL of 1.
BSR messages also contain:
The complete RP-set consisting of all C-RP announcements.
The IP Address of the BSR so that C-RPs know where to send their
announcements.
All routers receive the BSR messages being flooded throughout the network.
Select the active RP for each group range using a common hash algorithm
that is run against the RP-set. This results in all routers in the network
selecting the same RP for a given group-range.
BSR cannot be used with Admin-Scoping!
Admin scoping was not considered when BSR was designed. One problem
is that C-RP announcements that are unicast to the BSR cross multicast
boundaries. There are several other problems as well.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 18
PIMv2 BSR Fundamentals
Candidate RPs
Unicast PIMv2 C-RP messages to BSR
Learns IP address of BSR from BSR messages
Sent every rp-announce-interval (default: 60 sec)
C-RP messages contain:
Group Range (default = 224.0.0.0/4)
Candidates RP address
Holdtime = 3 x <rp-announce-interval>
Configured via global config command
ip pim rp-candidate <intfc> [group-list acl]
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 19
19
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 20
20
Bootstrap Router
The primary purpose of the Bootstrap router is to collect all C-RP
announcements in to a database called the RP -set and to periodically send the
RP-set out to all other routers in the network inside of BSR messages.
BSR Messages
Sent periodically (default: 60 secs) by the BSR out all multicast interfaces.
BSR messages are multicast to the All-PIM-Routers (224.0.0.13) group with
a TTL of 1. These messages are received by all PIM neighbors who
retransmit them (again with a TTL of 1) out all interfaces except the one in
which the messages was received. (An RPF check is done to insure the
BSR message came in on the correct interface in the direction of the BSR.)
BSR messages contain the RP-set and the IP address of the currently active
BSR. (This is how C-RPs know where to unicast their C-RP messages.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 21
21
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 22
22
BSR Election
How and when routers in the network forward BSR messages plays a key role in
the BSR election mechanism. The algorithm used to decide whether to process
and forward an incoming BSR message depends on whether the router is a
Candidate BSR or not.
BSR Message forwarding by C-BSR routers
C-BSRs operate in one of two states, Candidate-BSR or Elected-BSR. Initially,
a C-BSR comes up in C-BSR state.
C-BSR State
A BSR-Timeout timer started with a period of 150 seconds. If this timer expires,
the router transitions to the Elected-BSR State.
If a BSR message is received with higher priority than the C-BSRs priority, then
the BSR (whose address is in the BSR message) is considered to be preferred
and the BSR message is processed as follows:
The BSR-Timeout timer is reset.
The BSR message is forwarded out all other interfaces.
The RP-set in the BSR message is copied into the local Group-to-RP
mapping cache.
If a BSR message is received with a priority less than the C-BSRs priority, the
BSR message is simply discarded.
Elected BSR State
The router has been elected as the BSR and periodically originates BSR
messages containing the current RP-set.
If a BSR message is received from another router with a higher priority, forward
the BSR message and transition back to C-BSR state; otherwise discard the
BSR message.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 23
23
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 24
24
BSR Msgs
PIMv2
Sparse Mode F
BSR Msgs
C-
RP
nt Ad
me v
ise (un ertise
vert t) ica me
Ad as st) nt
RP (unic
C-
C-RP C-RP
B C
E
BSR Msgs Flooded Hop -by-Hop
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 25
25
BSR Example
Step 1
Candidate RPs unicast their C-RP messages to the previously elected
BSR. (The C-RPs learned the IP address of the BSR from the BSR
messages that are being flooded throughout the network.)
Step 2
The BSR receives and stores ALL C-RP information in a database called the
RP-Set (which is stored in the Group-to-RP mapping cache on Cisco
routers).
Step 3
The BSR periodically sends BSR messages containing the RP -set out all of
its interfaces. These BSR messages are forwarded hop-by -hop away from
the BSR by all routers in the network. The RP -set is used by all routers in
the network to calculate the RP for a group using a common hash algorithm.
Auto RP
PIMv2 BSR
Static RPs
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 26
26
Hard-coded RP address
When used, must be configured on every router
All routers must have the same RP address
RP fail-over not possible
Exception: If Anycast RPs are used. (See MSDP module.)
Command
ip pim rp-address <address> [group-list <acl>] [override]
Optional group list specifies group range
Default: Range = 224.0.0.0/4 (Includes Auto-
Auto- RP Groups!!!!)
Override keyword overrides Auto-RP information
Default: Auto-RP learned info takes precedence
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 27
27
Hard-code RP Addresses
Requires every router in the network to be manually configured with the IP
address of a single RP.
If this RP fails, there is no way for routers to fail-over to a standby RP.
The exception to this rule is if Anycast-RPs are in use. This requires
MSDP to be running between each RP in the network.
Command
ip pim rp-address <address> [group-list <acl>] [override]
The group-list allows a group range to be specified.
The default is ALL multicast groups or 224.0.0.0/4
DANGER, WILL ROBINSON!!!
The default range includes the Auto-RP groups (224.0.1.39 and 224.0.1.40)
which will cause this router to attempt to operate these groups in Sparse
mode. This is normally not desirable and can often lead to problems where
some routers in the network are trying to run these groups in Dense mode
(which is the normal method) while others are trying to use Sparse mode.
This will result in some routers in the network being starved of Auto-RP
information. This in turn, can result in members of some groups to not
receive multicast traffic.
The override keyword permits the statically defined RP address to take
precedence over Auto-RP learned Group-to-RP mapping information.
The default is that Auto-RP learned information has precedence.
Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 28
28
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 29
29
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 30
30
RP Performance Considerations
CPU Load Factors
The RP will receive all Register messages for any new sources in the
network. Although processing of Register messages is done at Process
Level, the impact on the router is usually small since the RP will immediately
send back a Register-Stop message.
The RP will receive and must process all Shared Tree Join/Prune messages
from downstream routers on the Shared Tree. Downstream routers
continue to send periodic (once a minute) Join/Prune messages up the
Shared Tree. The number of these Join/Prune messages is generally quite
small and therefore has little impact on the RP.
The RP must send periodic (once a minute) SPT Joins toward all sources
for which it has members active on a branch of the Shared Tree.
In order to detect a network topology change, ALL PIM routers perform an
RPF recalculation on every (*, G) and (S, G) entry in the mroute table every
5 seconds. The impact of this will grow as the total number of entries in the
mroute table increase and as the number of entries in the unicast routing
table increase. (The later is due to the fact that each RPF calculation
requires the route to the source to be looked up in the unicast routing table.
If this table is quite large, as would be the case for poorly aggregated
address space, the lookup can take more effort than when the number of
entries is kept small.) Except for the following load factor, this is the most
significant CPU load factor.
Any traffic that does have to flow through the RP requires it to replicate the
packets out all outgoing interfaces.
Memory Factors
The amount of memory consumed by PIM is primarily a function of the size
of the mroute table. (See the numbers in the slide for details.)
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 31
31
PIM
Sparse Mode
Network
scope 16 scope 16
C
Candidate-RP
A B
Mapping Mapping
Agent Agent
RP Announcements Not
Reaching this Map Agent
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 32
32
PIM
Sparse Mode
scope 32 scope 32 Network
C
Candidate-RP
A B
Mapping Mapping
Agent Agent
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 33
33
RP Discovery Messages
Not Reaching this Router
(Assumes All Groups
Are Dense Mode)
scope 16 scope 16
A
Mapping
D PIM Agent
Sparse Mode
Network
scope 32 scope 32
A
Mapping
D Agent
PIM
Sparse Mode
Network
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 35
35
Boundary
Router S0
scope 32 scope 32
A
Mapping
scope 32 scope 32 Agent
Interface S0
C ip multicast boundary 10
Candidate-RP PIM
access-list 10 deny 224.0.1.39
Sparse Mode access-list 10 deny 224.0.1.40
Network access-list 10 permit any
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 36
36
Interface S0 Interface S0
. .
. .
ip pim bsr-border ip pim bsr-border
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 37
37
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 38
38
Accept-RP Command
Global configuration commands
ip pim accept-rp <rp-address> [<acl>]
ip pim accept-rp Auto-rp [<acl>]
ip pim accept-rp 0.0.0.0 [<acl>]
Command format
ip pim accept-rp <rp-address> [<acl>]
ip pim accept-rp Auto-rp [<acl>]
ip pim accept-rp 0.0.0.0 [<acl>]
The option <acl> is used to specify which groups are valid using standard permit
and deny clauses.
Omitting the <acl> assumes a permit 224.0.0.0 15.255.255.255.
If more than one of the above commands is configured, they are sorted in the
order shown above.
The Auto-rp entry matches any RP address learned via Auto-RP.
(Note: This form has implied deny clauses for the Auto-RP groups, 224.0.1.39
and 224.0.1.40, that cannot be overridden in the optional <acl>. This helps
prevent the Auto-RP groups from accidentally switching to Sparse mode.)
The 0.0.0.0 (wildcard) matches any RP address.
While multiple ip pim accept-rp <rp-address> commands may be configured,
only a single Auto-rp and a single 0.0.0.0 (wildcard) command is accepted.
Search Rules
The list of configured commands is searched from top down and stops at the
first entry that matches the RP address.
The <acl> is applies and the RP is either permitted or denied.
Exception: If an Auto-RP entry denies an RP and a 0.0.0.0 entry exists, the
0.0.0.0 entry is also tried.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 40
40
Group-
to-RP Group
Group Address,
Address,
Group
Group Address
Address Permit
Permit Sparse
Sparse Mode
Mode
Mapping RP
RP Address
Address
Cache
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 41
41
(*, G) Join
B
B
Group
Group Address
Address
RP
RP Address
Address Process
Process Join
Join
RP
RP Address
Address
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 42
42
Source S B
B A
A RP
Accept-RP RP Processing
Filter List Engine
Group
Group Address,
Address,
Permit
Permit
RP Accept
Accept the
the
Interface
Interface Address
Address Register
Register
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 43
43
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 44
44
Filtering RP Announcements
Network Administrators may wish to configure Mapping Agents so that they will
only accept C-RP Announcements from well-known routers in the network. This
will prevent C-RP Announcements from bogus routers from being accepted and
potentially being selected as the RP.
Global Command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>]
The rp-list <acl> specifies the IP address(es) from which C-RP announcements
will be accepted.
The option group-list <acl> specifies the group range(s) that are acceptable for
the routers in the rp-list. If not specified, the default group-list <acl> is
deny all
Multiple instances of this command may be configured.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 45
45
Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 46
46
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 47
47
Debugging Auto-RP
First and foremost, you must understand the fundamental mechanisms behind
Auto-RP in order to debug problems!
Verify Group-to-RP Mapping Caches on Mapping Agents
Because other routers in the network will learn the Group-to-RP mapping
information from the Mapping Agents, it is important that this information is
correct on the Mapping Agents. If the information is not correct, verify that
the C-RPs are configured correctly and that C-RP Announcements are
being received properly by the Mapping Agent.
If multiple Mapping Agents are in use, make sure that their Group-to-RP
mapping information is identical. If not, the routers in the network will
oscillate between the different RPs selected by the Mapping Agents. Again,
make sure all Mapping Agents are properly receiving Auto-RP
Announcements from all C-RPs in the network. Watch out for TTL scoping
problems!
Verify Group-to-RP Mapping Caches on all other routers
Group-to-RP mapping information should match the MAs. If not, verify that
the router is properly receiving Auto-RP Discovery messages from the
Mapping Agents. Again, watch out for TTL scoping problems!
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 48
48
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 49
49
Static RPs
Auto RP
PIMv2 BSR
Tuning RP Operations
Debugging RP Operation
Special Cases
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 50
50
RP on a Stick
This is a special situation that occurs under the following conditions:
All branches of the Shared Tree are out a single interface on the RP (i.e.
there is only a single interface in the (*, G) OIL at the RP.)
All sources for the group are out the same interface. (This would result in
(S, G) entries with Null OILs since the incoming interface can never appear
in the OIL of an entry.)
Unusually State results in this condition
Special PIM rules had to be created that were not in the original PIMv2
specification in order to avoid situations where :
(S, G) traffic flows were incorrectly pruned.
(S, G) traffic continued to flow to the RP only to be dropped.
(S, G) state would get stuck in the RP and the First-Hop router even when
the source has long since stopped sending.
Problem was solved in IOS 12.0 by:
Special Proxy Join Timer and
Introduction of Atomic and Non-Atomic (*, G) Joins
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 52
52
RP-on-a-Stick Example
Consider that above network topology where both rtr-b and rtr-c share a
common Ethernet segment with the RP.
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Member
224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 53
53
RP-on-a-Stick Example
When a host behind rtr-c joins group 224.1.1.1, a branch of the Shared Tree is
created (shown by the solid arrow) which results in the following state on the
RP:
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 54
54
RP-on-a-Stick Example
This also results in the following state on rtr-c:
SPT E0 10.1.4.1
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 55
55
RP-on-a-Stick Example
Now assume that source 192.1.1.1 behind rtr-b begins sending to group
224.1.1.1. After the normal Register process has completed, a branch of the
SPT (shown by the heave dashed arrow) is built from rtr-b to the RP. This
allows traffic to flow to the members as shown by the thin dashed arrows.
SPT E0 10.1.4.1
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
(192.1.1.1/32,Source
224.1.1.1), 00:00:49/00:02:46, flags: T Member
192.1.1.1Ethernet0, RPF nbr 0.0.0.0,
Incoming interface: 224.1.1.1
Outgoing interface list:
Ethernet1, Forward/Sparse, 00:00:49/00:02:11
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 56
56
RP-on-a-Stick Example
The creation of the SPT results in the following state on rtr-b:
SPT E0 10.1.4.1
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
(192.1.1.1/32, 224.1.1.1),
Source 00:00:49/00:02:46, flags: PT
Incoming interface: Ethernet0, RPF nbr 10.1.4.2,
Member
192.1.1.1
Outgoing interface list: 224.1.1.1
RP-on-a-Stick Example
The creation of the SPT also results in the following state on the RP:
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 58
58
RP-on-a-Stick Solution
In order to deal of this special situation, several new concepts were added to the
12.0 implementation of PIM. These are:
Atomic vs. Non-Atomic (*, G) Joins
The Proxy Join Timer (and its flag) on (S, G) entries
Header-only Registers (aka Data-less Registers)
Each of the above are discussed in the following pages
Non-Atomic Joins
Contains (*, G) Join for group G only
This is the type of (*, G) Join we are familiar with
Atomic Joins
Contains (*, G) Join for group G followed by
(S, G)RP-bit Prunes for all sources in group G
Used to prune unnecessary (S, G) traffic from the Shared
Tree after switchover to the SPT.
All in the same PIM Join/Prune message
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 59
59
Non-Atomic Joins
This is a PIM Join/Prune message that contains only a (*, G) Join for group G
in the Join list without any associated (S, G)RP-bit Prunes for group G in the
Prune list.
This is the typical (*, G) Join that has been described in most of the
examples in Module 5, PIM -SM.
Atomic Joins
This is a PIM Join/Prune message that contains a (*, G) Join for group G in the
Join list AND a complete list of all (S, G)RP-bit Prunes for group G in the
Prune list.
Remember, these (S, G)RP -bit Prunes are used to Prune specific (S, G)
traffic off of the Shared Tree after a router has joined the SPT directly
toward the source.
Header
(10.1.19.21, 224.1.0.5)
(10.1.4.1, 224.3.3.3) WC, RP
(192.1.1.1, 224.1.1.1) RP
Prune List
(192.1.4.2, 224.2.2.2)
.
.
.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 60
60
Header
(10.1.19.21, 224.1.0.5)
(10.1.4.1, 224.3.3.3) WC, RP
(192.1.1.1, 224.1.1.1) RP
Prune List (192.1.4.2, 224.2.2.2)
.
.
.
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 61
61
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 62
62
Header-only Registers
Used to keep (S, G) state alive in the RP
Sent every 2 minutes by First-hop router
As long as source is still active
Continues sending until a Register-Stop is received
Register Messages contains null (S,G) data packet
Processed by the RP
Resets (S, G) entry timer at the RP
RP doesnt send Null packet down Shared Tree
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 63
63
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0,
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
00:02:43/00:02:17
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 64
64
RP-on-a-Stick Example
In this example, rtr-c is sending Non-Atomic (*, G) Joins to the RP to keep on
the Shared Tree. (Note that rtr-c has not joined the SPT at this point. This
could be due to the SPT-Threshold being set to Infinity.)
The RP is now running version 12.0 or later of IOS. Therefore, when the Non-
Atomic (*, G) Join for group 224.1.1.1 is received, the RP starts the Proxy Join
Timer in all (S, G) entries for group 224.1.1.1. This results in the following state
in the RP:
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0,
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
RP-on-a-Stick Example
The First-hop router (rtr-b) is also running version 12.0 or later of IOS and it will
therefore send periodic Header-only (S, G) Register messages to the RP.
When RP receives these Header-only (S, G) Registers, (roughly every 2
minutes), it resets the Expire timer in the corresponding (S, G) entry in the
Mroute table. This results in the following state in the RP:
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 66
66
Turnaround Router
As it turns out, the RP-on-a-Stick problem is actually a special case of another
problem referred to the Turnaround Router problem. This situation occurs
whenever :
There is only a single branch of the Shared Tree and
the Shared Tree and a SPT share a common path to the RP.
We want to have the (S, G) traffic flow along the SPT toward the RP and
turnaround at the appropriate router in the network and flow back down the
Shared Tree without sending unnecessary traffic to the RP.
Turnaround Router Solution
Once again, the new concepts of
Proxy Join Timer
Atomic and Non-Atomic Joins
Header-only Registers
permit the routers to solve this problem.
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 67
67
S0 10.1.3.2
rtr-x Turnaround Router
E0 10.1.4.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 68
68
S0 10.1.3.2
rtr-x Turnaround Router
E0 10.1.4.1
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S E0
Incoming interface: Null, RPF nbr 0.0.0.0,
Outgoing interface list:
Serial0, Forward/Sparse, 00:02:43/00:02:17
Notice that the Proxy Join Timer is running (note the X flag in the (S,G) entry.)
While the Proxy Join Timer is running, the RP will continue to send periodic
(S, G) Joins toward the source.
The Proxy Join Timer will be restarted each time the RP receives another
Non-Atomic Join from rtr-x.
10.1.4.2 E1 10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S
rtr-b
Incoming interface: Serial0, RPF nbr 10.1.3.1, rtr-c
Outgoing interface list:
E0
Ethernet0, Forward/Sparse, 00:02:43/00:02:17 E0
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: T
Incoming interface: Ethernet0, RPF nbr 10.1.4.2,
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:48/00:02:12
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 70
70
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 71
71
10.1.4.2 E1 10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S
Incoming interface: Serial0,
Serial0, RPF nbr rtr-b
nbr 10.1.3.1, rtr-c
Outgoing interface list:
E0
Ethernet0, Forward/Sparse, 00:02:43/00:02:17 E0
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT
Incoming interface: Ethernet0, RPF
RPF nbr
nbr 10.1.4.2,
10.1.4.2,
Outgoing interface list:
Serial0, Forward/Sparse, 00:00:48/00:02:12
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 72
72
Source Member
192.1.1.1 224.1.1.1
Proxy Join Timer eventually expires
(Non-Atomic Joins no longer being received)
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 73
73
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S
E0
Incoming interface: Serial0, RPF nbr 10.1.3.1, E0
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S E0
Incoming interface: Serial0, RPF nbr 10.1.3.1,
Outgoing interface list:
Ethernet0, Forward/Sparse, 00:02:43/00:02:17
10.1.4.2 E1 10.1.4.3 E1
rtr-b rtr-c
E0 E0
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 76
76
Turnaround Router
Step 11
Finally, Header-only Registers sent by the First-hop router (rtr-b) continue to
reset the Expire timer in the (S, G) entry at the RP. This prevents the (S, G)
entry from timing out and being deleted at the RP.
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 77
77
Turnaround Router
As a result of the Header-only Registers, the state in the RP will be as follows as
long as the source and member remain active:
10.1.4.2 E1 10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S
rtr-b
Incoming interface: Serial0, RPF nbr 10.1.3.1, rtr-c
Outgoing interface list:
E0
Ethernet0, Forward/Sparse, 00:02:43/00:02:17 E0
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT
Incoming interface: Ethernet0, RPF nbr 10.1.4.2,
Outgoing interface list:
Source Member
192.1.1.1 224.1.1.1
Module6. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 78
78
Turnaround Router
As a result of the Non-Atomic Joins, the state in the Turnaround router will be as
follows as long as the source and member remain active :
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 10:15 AM 1
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 2
2
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 3
3
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 4
4
Interface-Based Rate-Limiting
Limits total rate of all multicast flows in/out of
an interface
Flow-Based Rate-Limiting
Limits rate of each individual (S, G) or (*,G)
flow in/out of an interface
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 5
5
Interface-Based Rate-Limiting
Rate limits may be applied to the total overall rate of multicast traffic flowing into
or out of an interface. This is the most commonly used form of multicast rate
limiting, particularly for outgoing traffic. This permits an upper bound to be set
on the bandwidth consumed by multicast traffic on an interface.
Flow-Based Rate-Limiting
Flow-based rate limits may be applied to an interface on a Group or
Source/Group basis. When flow-based rate limits are defined, it causes the
rate to be applied to the incoming or outgoing interface of matching (*, G) or (S,
G) entries in the mroute table.
For example, if an outgoing 50Kbps flow-based rate limit has been configured on
interface Serial0 for (*, 224.1.1.1), then a 50Kbps rate limit will be set on Serial0
whenever it appears in the OIL of any (*, 224.1.1.1) or (S, 224.1.1.1) mroute
table entries. This will limit the rate of each these flows to a maximum of
50Kbps.
Note: Flow-based rate limiting is applied independently to each individual flow.
In the above example, this would limit each individual matching flow out Serial0
to 50Kbps. It would not rate limit the total flow of 224.1.1.1 traffic out Serial0 to
50Kbps. Therefore, if there were several sources for the 224.1.1.1 group, the
total flow can easily exceed 50Kbps.
Keywords such as video and whiteboard may be used to further identify
media specific flows on a UDP port basis. However, for this to work, ip sdr
listen must be configured so that the router can obtain the necessary SDR
session information to identify which flows are video and which are whiteboard.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 6
6
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8
8
Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output
interface-based rate-limits are shown on the entries in the outgoing interface list
(OIL) of each mroute table entry. The text following the OIL will have the word
Int preceding the rate limit value indicating that this is an Interface-based limit.
In the example above, an output interface-based rate-limit of 512kbps has been
configured on interface Serial0.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 9
9
Debugging Rate-Limits
Rate-limits may be displayed via the show ip mroute command. Input interface-
based rate-limits are shown on the incoming interface of each mroute table
entry. The text following the incoming interface information will have the word Int
preceding the rate limit value indicating that this is an Interface-based limit.
In the example above, an input interface-based rate-limit of 1 Mbps has been
configured on interface Ethernet0.
Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output flow-
based rate-limits are shown on the entries in the outgoing interface list (OIL) of
each mroute table entry. The text following the OIL will be missing the word Int
preceding the rate limit value. This indicates that this is an flow-based limit.
In the example above, an output flow-based rate-limit of 56kbps has been
configured on interface Serial1.
NOTE: Each individual matching flow will be rate-limited to 56kbps, not the
total aggregate of all matching flows. This means that if there are 10 active
flows that match the configured flow-based rate-limit, the total aggregate
rate out Serial1 could be as high as 560kbps!
128 Kbps
E0 100 Kbps
Video Server 2 S0
(192.2.2.2, 224.1.1.1) Total: 200 Kbps
E1 100 Kbps
128 Kbps
128 Kbps
E0 128 Kbps
Video Server 2 S0
(192.2.2.2, 224.1.1.1) Total: 256 Kbps!!!
E1 128 Kbps
128 Kbps
128 Kbps
E0 ??? Kbps
Video Server 2 S0
(192.2.2.2, 224.1.1.1) Total: 200 Kbps
E1 ??? Kbps
128 Kbps
Summary
Flow-based rate-limits do not limit the
total aggregate of all the matching
flows. Therefore, the use of interface-
based rate-limits are recommended
when an upper bound on multicast
traffic rates is desired.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 14
14
Summary
Flow-based rate-limits generally do not provide the sort of rate-limiting that is
very useful in real-world networks. As a result, only interface-based rate-limits
are normally used when an upper bound on multicast traffic is desired.
Border A
S0
S1
T1
T1
S0
S0
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 16
16
Admin-Scoping Example
In this example, two remote sites (Los Angeles and Atlanta) are linked to the
company HQ site via T1 lines.
Each of the three sites has its own Mapping Agent and a Site-Local RP that
serves the Site-Local group range 239.192.0.0/16 that was described in the
previous slide. This is necessary since the goal is to keep all Site-Local
traffic within each site and therefore each site must have its own
independent RP for this group range.
S1
Boundaries Boundaries
T1
T1
S0
S0
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 17
17
Admin-Scoping Example
The first step is to establish multicast boundaries that prevent Site-Local and
Organization-Local multicast traffic from crossing certain boundaries.
In the case of Site-Local traffic, these boundaries are established on the T1
links on each of the three border routers, A, B and C. The Site-Local
boundaries are implemented using the ip multicast boundary interface
command along with an access-control list that denies multicast traffic in
the Site-Local group range (239.192.0.0/16) from crossing this boundary.
The Organization-Local boundary is established on the link to the internet
and is also implemented using the ip multicast boundary interface
command. The access-control list for this boundary denies multicast traffic
in the Organization-Local group range (239.0.0.0/8) from crossing this
boundary.
S1
access-list 10 permit any
T1
T1
S0
S0
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 18
18
Admin-Scoping Example
The configuration commands necessary to establish the Site-Local boundaries
on border routers B and C are listed in the above drawing.
In both configurations, the Site-Local boundary is established on interface
Serial0 via the ip multicast boundary 10 interface command.
Access-control list 10 is constructed to deny the passage of any traffic in
the Site-Local group range (239.192.0.0/16) while all other multicast groups
are permitted to cross the interface.
Pay particular attention to the ip multicast ttl-threshold 16
command also configured on Serial0. The requirement for this command
will be discussed in a later slide.
Border A
S0
S1
T1
T1
Interface Serial0 S0
S0
. . .
ip multicast ttl-threshold 16 Border B Border C
ip multicast boundary 10
Interface Serial1
. . .
ip multicast ttl-threshold 16
Site
ip multicast boundary 10Local Site Local
RP/MA RP/MA
access-list 10 deny 239.192.0.0 0.0.255.255
access-list 10 permit anySite B (LA) Site C (ATL)
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 19
19
Admin-Scoping Example
The configuration commands necessary to establish the Site-Local boundaries
on border router A are listed in the above drawing.
In this case, the Site-Local boundary is established on both interface Serial0
and Serial1 via the ip multicast boundary 10 interface command.
Access-control list 10 is constructed to deny the passage of any traffic in
the Site-Local group range (239.192.0.0/16) while all other multicast groups
are permitted to cross the interface.
Again notice the ip multicast ttl-threshold 16 command also
configured on Serial0 and Serial1. The requirement for this command will
be discussed in a later slide.
S0
S1
T1
T1
S0
S0
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 20
20
Admin-Scoping Example
The next step is to configure the independent Mapping Agents for each site as
well as the independent Site-Local group RP. In the drawing above, the
configuration for the RP/Mapping Agent in Site B is shown.
In this case, interface Loopback0 has been configured for use as the
interface of choice for the Mapping Agent and RP. A loopback interface is
often used for this purpose as it provides more flexibility in the management
of the Mapping Agent as well as the selection of the RP when multiple
candidate RPs are define. (The highest candidate IP address is chosen as
the active RP by Mapping Agents.)
The ip pim send-rp-discovery global command defines the router
as a Mapping Agent for Site B with an IP address of the loopback interface.
Note that a TTL scope of 15 is used on this command so that the Discovery
messages sourced by this Mapping Agent will not exit the Site. (This is
accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
The ip pim send-rp-announce global command along with access-
control list 20, defines the router as a Candidate RP for the Site-Local group
range. Note that a TTL scope of 15 is used on this command so that the
Announce messages sourced by this Candidate-RP will not exit the Site.
This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
Note: It is crucial that the Candidate-RP Announce messages do not leak
outside of this site and into other sites. If this were to occur, the Mapping
Agent(s) in the other site(s) might select the Candidate-RP in Site B as the
currently active RP for the Site-Local group. This would break Site-Local
multicast in that site.
S0
access-list 20 permit 239.192.0.0 0.0.255.255
S1
T1
T1
S0
S0
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 21
21
Admin-Scoping Example
In the drawing above, the configuration for the RP/Mapping Agent in Site C is
shown.
Interface Loopback0 has also been configured for use as the interface of
choice for the Mapping Agent and RP.
The ip pim send-rp-discovery global command defines the router
as a Mapping Agent for Site C with an IP address of the loopback interface.
Note once again that a TTL scope of 15 is used on this command so that the
Discovery messages sourced by this Mapping Agent will not exit the Site.
(This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
The ip pim send-rp-announce global command along with access-
control list 20, defines the router as a Candidate RP for the Site-Local group
range. Note that a TTL scope of 15 is used on this command so that the
Announce messages sourced by this Candidate-RP will not exit the Site.
This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
Note: It is crucial that the Candidate-RP Announce messages do not leak
outside of this site and into other sites. If this were to occur, the Mapping
Agent(s) in the other site(s) might select the Candidate-RP in Site C as the
currently active RP for the Site-Local group. This would break Site-Local
multicast in that site.
Border A
S0
S1
T1
T1
S0
S0
interface Loopback0
Border B 255.255.255.255
ip address 192.168.10.3 Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 22
22
Admin-Scoping Example
In the drawing above, the configuration for the RP/Mapping Agent in Site A is
shown.
Interface Loopback0 has also been configured for use as the interface of
choice for the Mapping Agent and RP.
The ip pim send-rp-discovery global command defines the router
as a Mapping Agent for Site A with an IP address of the loopback interface.
Note once again that a TTL scope of 15 is used on this command so that the
Discovery messages sourced by this Mapping Agent will not exit the Site.
(This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
The ip pim send-rp-announce global command along with access-
control list 20, defines the router as a Candidate RP for the Site-Local group
range. Note that a TTL scope of 15 is used on this command so that the
Announce messages sourced by this Candidate-RP will not exit the Site.
This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was
configured in the previous slides.)
Note: It is crucial that the Candidate-RP Announce messages do not leak
outside of this site and into other sites. If this were to occur, the Mapping
Agent(s) in the other site(s) might select the Candidate-RP in Site A as the
currently active RP for the Site-Local group. This would break Site-Local
multicast in that site.
Border A
S0 Main RP/MA
S1
(non-Site Local Groups)
T1
T1
S0
interface Loopback0
S0
ip address 192.168.1.3
Border B255.255.255.255
Border C
ip pim send-rp-discovery Loopback0 scope 64
ip pim send-rp-announce Loopback0 scope 64 group 20
ip pim rp-
rp -announce
announce--filter rp-
rp -list 10
access
access-
Site -Local
list 10 deny 192.168.10.3 Site Local
access-
access -list 10 permit any
RP/MA RP/MA
Site B (LA)
access-list 20 permit 224.0.0.0 0.255.255.255 Site C (ATL)
access-list 20 permit 225.0.0.0 0.255.255.255
. . .
access-list 20 permit 238.0.0.0 0.255.255.255
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 23
23
Admin-Scoping Example
Next, an RP for all the non-Site-Local multicast groups must be configured.
Border router A has been chosen for this task. Additionally, router A is
configured as a Mapping Agent with sufficient scope to cover the entire network.
(Note: The independent Mapping Agents for each site make this step
unnecessary as they can handle the Mapping Agent functionality for their site.)
Once again, interface Loopback0 has been configured for use as the
interface of choice for the Mapping Agent and RP.
The ip pim send-rp-announce global command along with access-
control list 20, defines the router as a Candidate RP for all non-Site-Local
groups. Note that a TTL scope of 64 is used on this command so that the
Announce messages sourced by this Candidate-RP will reach all routers in
all Sites.
The ip pim send-rp-discovery global command defines the router
as a Mapping Agent for the entire network. Note that a TTL scope of 64 is
also used on this command so that the Discovery messages sourced by this
Mapping Agent reach all routers in all Sites.
Because the scope of the Discovery messages are 64, they will reach all
routers in all sites. Therefore, care must be taken to insure that the C-RP
information from the Site-Local C-RP in the HQ site is not accepted and
inadvertently advertised in Discovery messages by the Mapping Agent. If
this were to occur, the routers in the other site(s) might select the
Candidate-RP in the HQ Site as the currently active RP for the Site-Local
group. This would break Site-Local multicast in that site. To prevent this
from happening, the ip pim rp-announce-filter command along
with access-control list 10 is used to filter out C-RP Announcement
messages from the Site-Local C-RP in the HQ Site.
Note: This problem can be avoided if router A is not configured as a
Mapping Agent.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module7.ppt 23
BW Control via Admin-Scoping
Site A (HQ)
AS Border
To Internet
Site Local S0
RP/MA
Border A
Interface Serial0
. . .
S0
S1
ip multicast ttl-threshold 128
ip multicast boundary 10
T1
T1
access-list 10 deny 239.0.0.0 0.0.0.255
S0 10 permit any
S0
access-list
Border B Border C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 24
24
Admin-Scoping Example
Finally, the AS Border router must be configured with a multicast boundary so
that all locally scoped multicast traffic in the 239.0.0.0/8 range is blocked from
entering or leaving the company.
In this configuration, the multicast boundary is established on interface
Serial0 via the ip multicast boundary 10 interface command.
Access-control list 10 is constructed to deny the passage of any traffic in
the Admin-Scoped group range (239.0.0.0/8) while all other multicast groups
are permitted to cross the interface.
Although it is not necessary to implement Admin-Scoping, the ip
multicast ttl-threshold 128 command is also configured on
Serial0 of the AS border router. This is often used to provide TTL scoping of
traffic inside of the company. Sources that do not wish to have their
multicast traffic leave the company can transmit with a TTL less than 128
and be insured that the traffic will not be forwarded into the Internet.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 25
25
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 26
26
RPF
Calculation
(Best Path)
BGP Route/Mask, Dist. (Use best
MRIB (eBGP Def. Dist.=20) Distance
(iBGP Def. Dist.=200) unless
IIF, RPF Neighbor
Longest
DVMRP (Longest Match) Match1 is
Route Route/Mask, Dist. enabled.
Table (Default Dist. = 0) If enabled,
use longest
Mask.)
(Longest Match)
Unicast
Routing Route/Mask, Dist.
Table
1 Global Command: ip multicast longest-match
Module7.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 27
27
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 28
28
Static Mroutes
A Static Mroute may be configured using the command listed above to match
based on the <source> and <mask> parameters.
Either an <rpf-nbr> address or a specific <interface> can be configured as
the next-hop.
An optional <protocol> may be configured which requires that a matching
route must exist in the specified unicast routing protocols database for the
Static Mroute to match.
An optional route-map <map> clause may be configured to constrain the
match to the qualifications specified in the route-map in order for the Static
Mroute to match.
The default Admin. Distance of a Static Mroute is zero. This value may be
overridden by the use of the <distance> parameter.
If multiple Static Mroutes are configured, they are searched for a match in the
order in which they were configured. If a match is found, the search terminates
and the Static Route is used if it has an Admin. Distance less than or equal to
any other source of RPF information.
Note: Unlike their unicast counterparts, Static Mroutes only have significance on
the router on which they are defined and cannot be redistributed.
Central Site
tunnel0
MR
UR
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 29
29
Central Site
OSPF Domain
tunnel0
MR
UR
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 30
30
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 31
31
DVMRP Unicast
PIM Router Route Route
Table Table
* Split-Horizon is used between two Cisco
routers.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 32
32
176.32.10.0/24 176.32.15.0/24
ip dvmrp unicast-routing
ip dvmrp metric 1
172.16.10.0/24
172.16.15.0/24
172.16.1.0/24
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 34
34
DVMRP Report
172.16.10.0/24
172.16.15.0/24
172.16.1.0/24
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 35
35
Source C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 36
36
access-list 10
access-list 10
permit 172.16.15.0
permit 172.16.15.0 0.0.0.255
0.0.0.255
permit 172.16.10.0
permit 172.16.10.0 0.0.0.255
0.0.0.255
172.16.10.0/24
172.16.15.0/24
172.16.1.0/24
Source C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 37
37
172.16.10.0/24, M=1
172.16.15.0/24, M=1
DVMRP Report
172.16.10.0/24
172.16.15.0/24
172.16.1.0/24
Source C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 38
38
Source C
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 39
39
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 40
40
CONCLUSION
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 41
41
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 42
42
Tunneling Multicast
Cisco IOS supports two types of tunnels for IP Multicast traffic. Both of these
tunnel modes are fast-switched.
DVMRP Tunnels - This is actually an IP-in-IP tunnel and uses the protocol
number of 4. DVMRP tunnels are not supported between two Cisco routers.
It is solely intended for use between a Cisco router and a non-Cisco router
running DVMRP.
GRE Tunnels - IP Multicast traffic may be tunneled between two Cisco
routers using GRE tunnels (protocol 47).
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 43
43
DVMRP Tunnels
DVMRP tunnels are only used between Cisco routers and non-Cisco DVMRP
routers. DVMRP tunnels cannot be used between two Cisco routers!
A normal tunnel configuration (such as the one shown above) is used with the
tunnel mode set to dvmrp.
GRE Tunnels
When it is necessary to tunnel multicast traffic between two Cisco routers, a
GRE Tunnel must be used.
The GRE Tunnel appears as a point-to-point link to both ends. Each packet
sent down the tunnel gets an extra IP header. GRE tunnels also provide data
sequencing and some degree of security.
A normal tunnel configuration (such as the one shown above) is used with the
tunnel mode set to gre ip.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 45
45
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 46
46
SPT Thresholds
The key advantage of a Shared Tree is that all multicast flows in the group may
use the Shared Tree thereby reducing the amount of multicast forwarding state
in the routers in the network. However, the (normally) sub-optimal paths of the
Shared Tree introduce additional delay and possible points of congestion along
the single common tree.
Switching to Sources Trees (aka Shortest-Path Trees or SPT for short) is the
default behavior of Ciscos PIM implementation. The advantage of Source
Trees is that multicast flows via the shortest path from the sources to the
receivers which reduces latency and the potential for congestion. However, this
is accomplished at the expense of more multicast forwarding state in the routers
in the network.
SPT Thresholds permit the network engineer to tune at what point in terms of
kbps a last-hop router switches to the SPT.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 47
47
SPT Thresholds
SPT Thresholds may be configured on a router using the global configuration
command shown above.
<kbps> | infinity - Defines at what rate in kbps a last-hop router
switches to the SPT. If the value of infinity is used
the router will never switch to the SPT and traffic will
only flow down the Shared Tree.
group-list <acl> - Option ACL that defines the groups for which the
SPT-threshold is applicable. If this ACL is not
specified, all multicast groups are assumed.
SPT-Thresholds must be configured on each individual router in the network. It
will not have the desired affect if it is only configured on the RP. (This is
because the RP does not communicate this value to the routers in the network.)
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 48
48
SPT-Threshold Example
In the above example, the network engineer desires to force all multicast traffic
in the 224.2.0.0/16 group range to never switch to the SPT. This will help
reduce the amount of multicast forwarding state in the network for this group at
the expense of sub-optimal routing paths.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 49
49
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 50
50
10.1.1.0/24
Broadcast .1 Multicast
E0 A
ip multicast helper-map broadcast 224.1.1.1 100 ttl 15
ip forward-protocol udp 2000
access-list 100 permit any any udp 2000
any any
Broadcast Broadcast Multicast
udp 2000
(10.1.1.10, 10.1.1.255) (10.1.1.10, 10.1.1.255) (10.1.1.10, 224.1.1.1
224.1.1.1)
UDP Port 2000 UDP Port 2000 UDP Port 2000
MATCH!
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 51
51
10.2.2.0/24
.1
Multicast S0 E0 Broadcast
B
any any
Multicast Multicast Broadcast
udp 2000
(10.1.1.10, 224.1.1.1) (10.1.1.10, 224.1.1.1) (10.1.1.10, 10.2.2.255
10.2.2.255)
UDP Port 2000 UDP Port 2000 UDP Port 2000
MATCH!
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 52
52
10.1.1.0/24
10.2.2.0/24
.1 Multicast Capable .1
E0 S0 Network S0 B E0
A
ip multicast helper-map
Interface Ethernet0
ip address 10.1.1.1 255.255.255.0
ip directed-broadcasts
ip multicast helper-map broadcast 224.1.1.1 100 ttl 15
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 53
53
10.1.1.0/24
10.2.2.0/24
.1 Multicast Capable .1
E0 S0 Network S0 B E0
A
ip multicast helper-map
Interface Serial0
ip address 172.16.255.2 255.255.255.252
ip multicast helper-map 224.1.1.1 10.2.2.255 100
ip igmp join-group 224.1.1.1
interface Ethernet0
ip address 10.2.2.1 255.255.255.0
ip directed-broadcast
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 54
54
10.1.1.0/24
10.2.2.0/24
.1 Multicast Capable .1
E0 S0 Network S0 B E0
A
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 55
55
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 56
56
RP failover time
Function of Holdtime in RP-Announcement
Holdtime = 3 x <rp-announce-interval>
Default < rp-announce-interval> = 60 seconds
Worst-case (default) Failover ~ 3 minutes
Minimizing impact of RP failure
Use SPTs to reduce impact
Traffic on SPTs not affected by RP failure
Immediate switch to SPTs is on by default
New and/or bursty sources still a problem
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 57
57
RP Failover
The time it takes for the network to detect the failure of the active RP and switch
to a backup RP depends on the value of the Holdtime field in the RP-
Announcement.
The Holdtime field indicates when the RP will timeout and assumed to be
down if another RP-Announcement is not received by the Mapping Agent.
Holdtime is computed as 3 times the RP-Announce-Interval which has a
default value of 60 seconds. This results in Holdtime values of 3 minutes
which is the worst case failover time.
The use of SPTs will reduce the affect of an RP failure since the Shared Tree is
not being used to deliver multicast traffic. Therefore, if the RP fails, traffic from
currently active sources will continue to flow to currently active receivers.
However, new sources and or new receivers will not be able to register or join
the Shared Tree until the RP failure has been detected and a switch to a backup
RP occurs.
Note: There is no failover mechanism built in to PIM for Static-RPs. In order to
use backup RPs, either Auto-RP or BSR must be used. (A special configuration
called Anycast RP can be used if multiple static RPs are desired. This
configuration, however, requires the use of MSDP and is not a native function of
the PIM Protocol.)
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 58
58
Tuning RP Failover
Prior to IOS release 12.0, the rp-announce-interval was fixed at 60 seconds.
Beginning with IOS 12.0, the interval <seconds> clause was added to the
ip send-rp-announce command. This new clause allows this interval to be
tuned and hence tunes the Holdtime advertised in the RP Announcements.
By reducing the rp-announce-interval, RP failure is detected sooner and
therefore failover to the backup RP occurs sooner. However, the reduced
intervals between announcements results in an increase in RP Announcement
traffic in the network. This is generally insignificant and worth the reduced RP
failover times.
The minimum rp-announce-interval that may be set is 1 second. This
corresponds to a worst case failover of 3 seconds.
A B
.2 (DR) 192.168.1.0/24 .1
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 59
59
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 60
60
Tuning DR Failover
The DR Failover process can be indirectly tuned by varying the PIM query
interval on the interface. This is accomplished using the following IOS interface
command:
ip pim query-interval <seconds>
By reducing this value from its default of 30 seconds, the period between PIM
Hello messages is reduced as well as the expiration time advertised in the PIM
Hello message.
The minimum query interval that can be configured is 1 second. This results in
an expiration time of 3 seconds which is the worst case scenario for DR
failover. However, reducing the query interval from its default of 30 seconds
increases the amount of PIM Hello traffic on the local LAN. In most cases, this
is an acceptable trade-off when faster DR Failover is desired.
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 61
61
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 62
62
Full Mesh A
NBMA Network S0 .1
Logical IP Subnet
192.1.1.0/24
Frame Relay
or ATM
S0 S0
.2 .3
B C
Physical Interface
S0 .4
Virtual Circuit
D
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 63
63
Partial Mesh A
NBMA Network S0 .1
Logical IP Subnet
192.1.1.0/24
Frame Relay,
ATM or Dialup
S0 S0
.2 .3
B C
Remote Site Remote Site
Router Router
Physical Interface
S0 .4
Virtual Circuit
Remote Site
D
Router
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 64
64
S0 .1
Layer 3 Viewpoint
Interface S0
ip address 192.1.1.1 255.255.255.0
ip pim sparse-dense-mode
192.1.1.0/24
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 65
65
Layer 3 Viewpoint
When a point-to-multipoint NBMA network is configured using a LIS (as
described in the previous slides), the router sees only a single physical interface
from a Layer 3 perspective.
In the above example, the Central Site router sees Serial0 as a single interface
that is connected to the Remote site routes. Furthermore, this single interface
appears (from a Layer 3 point of view) as having the same characteristics as an
Ethernet. That is to say, any broadcast or multicast packet sent on Serial0 will
reach all remote site routers.
Virtu
Vi
it
rtu
ircu
uit
al
irc
al Cir
Ci
C
lC
l
rc
tua
uit
tua
Vir
cuit
Vir
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 66
66
Layer 2 Reality
The Layer 2 reality is shown In the above example. The Central Site actually has
separate VCs configured on Serial0 that connect it to all of the other remote site
routers.
S0 .1
Layer 3 Viewpoint
(*, 224.1.1.1), 00:00:12/00:00:00, RP 10.1.1.1, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: 192.1.1.0/24
Serial0, Forward/Sparse, 00:00:12/00:02:48
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 67
67
S0 .1
Layer 3 Viewpoint
192.1.1.0/24
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 68
68
S0 .1
Layer 2 Reality
192.1.1.0/24
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 69
69
S0 .1
Layer 3 Viewpoint
192.1.1.0/24
(S, G) Prune
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 70
70
(S, G) Prune
Other routers S0 .2 S0 .3 S0 .4 S0 .5
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 71
71
S0 .1
Layer 2 Reality
192.1.1.0/24
S0 .2 S0 .3 S0 .4 S0 .5
(S, G) traffic
is shut off !
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 72
72
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 73
73
S0 .1
Interface S0 192.1.1.0/24
ip address 192.1.1.1 255.255.255.0
ip pim sparse-dense-mode
ip pim nbma-mode
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 74
74
S0 .1
192.1.1.0/24
(*, G) Join
(*, G) Join (*, G) Join
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 75
75
S0 .1
192.1.1.0/24
(*, 224.1.1.1), 00:03:23/00:00:00, RP 10.1.1.1, flags: S
Incoming interface: Ethernet0, RPF nbr 10.1.1.1
Outgoing interface list:
Serial0, 192.1.1.2, Forward/Sparse, 00:00:12/00:02:48
Serial0, 192.1.1.3, Forward/Sparse, 00:03:23/00:01:36
Serial0, 192.1.1.4, Forward/Sparse, 00:00:48/00:02:12
S0 .2 S0 .3 S0 .4 S0 .5
Remote Site
Routers
Members
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 76
76
S0 .1
192.1.1.0/24
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 77
77
A
S0 .1
Layer 2 Reality
Not heard by the
192.1.1.0/24
other routers!!!
Auto-RP Messages
Announce
messages S0 .2 S0 .3 S0 .4 S0 .5
Discovery
messages B C D E
C-RP or MA
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 78
78
Auto-RP Messages
Announce
messages
S0 .2 S0 .3 S0 .4 S0 .5
Discovery
messages
B C D E
C-RP
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 79
79
S0 .2 S0 .3 S0 .4 S0 .5
B C D E
MA
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 80
80
P2P PVCs
ATM NBMA Cloud with Pseudo Broadcast
ATM NBMA Cloud with PIM NBMA-Mode
ATM NBMA Cloud with a P2MP Broadcast SVC
ATM NBMA Cloud with a P2MP SVC per Group
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 81
81
Router Backbone
ATM Each PVC is a p2p
subinterface
B C
Each PVC is a
separate subnet
ATM fabric modeled as a
D collection of p2p links to
IPmc
Use any PIM mode
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 82
82
Comments
Could use static PVCs or soft PVCs on the ATM switches
Could use SVCs with mapping and broadcast (PVCs more stable)
Advantages
Works well when p2mp VCs are not available
Effective pruning and excellent configuration control since each VC looks like a
separate interface
Fast switching supported
Disadvantages
Router does replication - watch out for high bandwidth flows and/or high fanout
More configuration - more links, more subinterfaces, etc
Multiple copies of packet on the ATM fabric (unlike p2mp VCs)
Scalability - configuration gets larger as # of routers in mesh gets large
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 83
83
Comments
Identical to Frame Relay cloud but over ATM
Could use static PVCs
Could use SVCs with mapping and broadcast (PVCs more stable)
Advantages
Easy to configure.
Works with any PIM mode.
Disadvantages
Router does replication - watch out for high bandwidth flows and/or high fanout
Fast switching not supported
Multiple copies of packet on the ATM fabric (unlike p2mp VCs)
Scalability - configuration gets larger as # of routers in mesh gets large
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 84
84
Comments
Identical solution to example in the NBMA mode section but over ATM
Could use static PVCs or soft PVCs on the ATM switches
Could use SVCs with mapping and broadcast (PVCs more stable)
Advantages
Traffic only goes to members who have joined the group via PIM SM even
though its a multipoint interface (I.e. we just dont replicate to each neighbor
who has a broadcast map)
Works well when p2mp VCs are not available
Effective pruning since we can control replication to each neighbor/VC
Fast switching supported
Disadvantages
Router does replication - watch out for high bandwidth flows and/or high fanout
More configuration - more links, more subinterfaces, must configure map list
commands, etc
Multiple copies of packet on the ATM fabric (unlike p2mp VCs)
Scalability - configuration gets larger as # of routers in mesh gets large
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 85
85
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 86
86
Comments
Leverage ATM fabric to do the broadcast/multicast replication vi a a single p2mp
VC
Could use static P2P PVCs or soft PVCs on the ATM switches
Advantages
ATM fabric does the replication instead of the router
Off-loads router CPU
Only one packet sent to the ATM fabric
Fast switching supported
Disadvantages
All ATM routers get all the multicast groups even if they dont care about some
of them
ATM fabric must support p2mp VCs and have good replication performance
Leafs of the p2mp VC are configured with map-list commands with the
broadcast keyword
Only useful for router-to-router backbones
Command:
atm multipoint-signaling
Requires broadcast keyword
on all ATM map-list statements
atm map-list mumble
ip x.x.x.x atm-nsap xxxx.xxxx broadcast
ip y.y.y.y atm-nsap yyyy.yyyy broadcast
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 87
87
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 88
88
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 89
89
Comments
Leverage ATM fabric to do the multicast replication via a p2mp VC per Group
Could use static P2P PVCs or soft PVCs on the ATM switches
Router cannot support unlimited number of p2mp VCs. Therefore Group to
p2mp VC mapping is limited to a configured number of Groups.
A rate threshold can be set to cause low traffic Groups to drop back to the
shared broadcast p2mp VC.
Advantages
ATM fabric does the replication instead of the router
Off-loads router CPU
Only one packet sent to the ATM fabric
Fast switching supported
Disadvantages
ATM fabric must support p2mp VCs and have good replication performance
Leafs of the p2mp VC are configured with map-list commands with the
broadcast keyword
Only useful for router-to-router backbones
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 90
90
Commands:
ip pim multipoint-signalling
ip pim vc-count <number>
ip pim minimum-vc-rate <pps>
Good for single LIS which is fully meshed
Need the shared broadcast p2mp SVC
otherwise uses Pseudo-Broadcast (ugh!)
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 91
91
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 92
92
rtr-a>
rtr-a> show
show atm
atm vc
vc
AAL
AAL // Peak
Peak Avg.
Avg. Burst
Burst
Interface
Interface VCD
VCD VPI
VPI VCI
VCI Type
Type Encapsulation
Encapsulation Kbps
Kbps Kbps
Kbps Cells
Cells Status
Status
ATM0/0
ATM0/0 11 00 55 PVC
PVC AAL5-SAAL
AAL5-SAAL 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 22 00 16
16 PVC
PVC AAL5-ILMI
AAL5-ILMI 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 33 00 124
124 MSVC-3
MSVC-3 AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 44 00 125
125 MSVC
MSVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 55 00 126
126 MSVC
MSVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 66 00 127
127 MSVC
MSVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 99 00 130
130 SVC
SVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 10
10 00 131
131 SVC
SVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 11
11 00 132
132 MSVC-3
MSVC-3 AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 12
12 00 133
133 MSVC-1
MSVC-1 AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 13
13 00 134
134 SVC
SVC AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 14
14 00 135
135 MSVC-2
MSVC-2 AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
ATM0/0
ATM0/0 15
15 00 136
136 MSVC-2
MSVC-2 AAL5-SNAP
AAL5-SNAP 155000
155000 155000
155000 96
96 ACT
ACT
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 or
or VCD,
VCD, State/Mode
State/Mode
(*,
(*, 224.1.1.1),
224.1.1.1), 00:03:57/00:02:54,
00:03:57/00:02:54, RP
RP 130.4.101.1,
130.4.101.1, flags:
flags: SJ
SJ
Incoming
Incoming interface:
interface: Null,
Null, RPF
RPF nbr
nbr 0.0.0.0
0.0.0.0
Outgoing
Outgoing interface
interface list:
list:
ATM0/0,
ATM0/0, VCD
VCD 3,
3, Forward/Sparse,
Forward/Sparse, 00:03:57/00:02:53
00:03:57/00:02:53
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 94
94
ATM0/0:
ATM0/0: VCD:
VCD: 3,3, VPI:
VPI: 0,
0, VCI:
VCI: 124,
124, etype:0x0,
etype:0x0, AAL5
AAL5 -- LLC/SNAP,
LLC/SNAP, Flags:
Flags: 0x650
0x650
PeakRate:
PeakRate: 155000,
155000, Average
Average Rate:
Rate: 155000,
155000, Burst
Burst Cells:
Cells: 96,
96, VCmode:
VCmode: 0xE000
0xE000
OAM
OAM DISABLED,
DISABLED, InARP
InARP DISABLED
DISABLED
InPkts:
InPkts: 0,
0, OutPkts:
OutPkts: 12,
12, InBytes:
InBytes: 0,0, OutBytes:
OutBytes: 496
496
InPRoc:
InPRoc: 0,
0, OutPRoc:
OutPRoc: 0,0, Broadcasts:
Broadcasts: 12 12
InFast:
InFast: 0,
0, OutFast:
OutFast: 0,0, InAS:
InAS: 0,
0, OutAS:
OutAS: 00
OAM
OAM F5
F5 cells
cells sent:
sent: 0,
0, OAM
OAM cells
cells received:
received: 00
Status:
Status: ACTIVE,
ACTIVE, TTL:
TTL: 2,2, VC
VC owner:
owner: IPIP Multicast
Multicast (224.1.1.1)
(224.1.1.1)
interface
interface == ATM0/0,
ATM0/0, call
call locally
locally initiated,
initiated, call
call reference
reference == 22
vcnum
vcnum == 11,
11, vpi
vpi == 0,
0, vci
vci == 132,
132, state
state == Active
Active
aal5snap
aal5snap vc,
vc, multipoint
multipoint call
call
Retry
Retry count:
count: Current
Current == 0,
0, Max
Max == 10
10
timer
timer currently
currently inactive,
inactive, timer
timer value
value == 00:00:00
00:00:00
Leaf
Leaf Atm
Atm Nsap
Nsap address:
address: 47.0091810000000002BA08E101.444444444444.02
47.0091810000000002BA08E101.444444444444.02
Leaf
Leaf Atm
Atm Nsap
Nsap address:
address: 47.0091810000000002BA08E101.333333333333.02
47.0091810000000002BA08E101.333333333333.02
Leaf
Leaf Atm
Atm Nsap
Nsap address:
address: 47.0091810000000002BA08E101.222222222222.02
47.0091810000000002BA08E101.222222222222.02
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 96
96
IETF draft
draft-speakman-pgm-spec-??.txt
Routers assist the retransmit process
NAK suppression mechanism
Retransmission constraint mechanism
Maintain NAK/retransmission state only
Important point:
Routers dont do the retransmitting
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 97
97
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 98
98
N20
N20 N21
N21
NCF (Multicast)
NAK (Unicast) R12
N10
N10 N11
N11
R11
TSI/SQN Retransmission
-1 OIF State
N00
N00 N01
N01
X
Packet Lost
PGM Example
When a retransmission is needed to make up for a lost packet, a sequence of
events occurs. This sequence is collectively depicted by this slide and the
following three slides.
Upon detection of a missing data packet (error), a receiver repeatedly unicasts a
NAK to the last-hop PGM router on the distribution tree from the source. A
receiver repeats this NAK until it receives a NAK confirmation (NCF) multicast to
the group from that PGM router. That router responds with an NCF to the first
occurrence of the NAK and any further retransmissions of that same NAK from
any receiver.
TSI/SQN Retransmission
N20 -1 OIF State
N20 N21
N21
NCF (Multicast)
NAK (Unicast) R12
N10
N10 N11
N11
R11
N00
N00 N01
N01
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 100
100
PGM Example
In turn, the router repeatedly forwards the NAK to the upstream PGM router on
the reverse of the distribution path from the source of the original data packet
until it also receives an NCF from that router.
N20
N20 N21
N21
NCF (Multicast)
NAK (Unicast) R12
N10
N10 N11
N11
R11
N00
N00 N01
N01
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 101
101
PGM Example
In turn, the router repeatedly forwards the NAK to the upstream PGM router on
the reverse of the distribution path from the source of the original data packet
until it also receives an NCF from that router. This occurs repeatedly as
needed.
TSI/SQN Retransmission
N20 -1 OIF State
N20 N21
N21
NCF (Multicast)
NAK (Unicast) R12
Retransmission N10
N10 N11
N11
R11
TSI/SQN Retransmission
N00
N00 N01
N01
-1 OIF State
Module7. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 102
102
PGM Example
Finally, the source itself receives and confirms the NAK by multicasting a NCF
to the group. The source then retransmits the missing data packet to the group
address.
PGM routers on the way forward the retransmitted packet according to the
retransmission state in them - if the retransmission state exists the packet is
forwarded to the interfaces via which NAKs were received.
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 1
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 2
2
Module Agenda
DVMRP Overview
DVMRP Packet Formats
DVMRP Basic Concepts
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 3
3
Distance vector-based
Similar to RIP
Infinity = 32 hops
Subnet masks in route advertisements
Routing information carried in
IGMP packets
IP Protocol 2 (IGMP)
IGMP type 0x13 (DVMRP)
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 4
4
DVMRP Overview
DVMRP is a Distance vector based protocol that is modeled after RIPv1 with the
following fundamental differences:
Infinity = 32 (hops)
Subnet masks are sent in the route advertisements which make DVMRP a
Classless protocol.
DVMRP also makes special use of Poison-Reverse advertisements which is
explained in the following slides.
DVMRP routing information is carried inside of IGMP (IP protocol 2) packets.
Therefore, if you are trying to capture a DVMRP conversation using equipment
like a Network General Sniffer, you will need to capture IGMP packets and
futher decode them.
The IGMP type code for DVMRP is 0x13.
Similar to PIM DM
Broadcast and prune operation
Uses DVMRP route table for RPF check
Virtual interfaces
Physical: Ethernet, FDDI, Token Ring, etc.
Tunnels: IP-in-IP tunnels (IP Protocol 4)
Current version
mrouted 3.9
Available for most UNIX environments
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 5
5
DVMRP Probes
for DVMRP Neighbor Discovery
DVMRP Reports
for Multicast Route Exchange
DVMRP Prunes
for pruning multicast delivery trees
DVMRP Grafts
for grafting multicast delivery trees
DVMRP Graft Acks
for acknowledging graft msgs
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 6
6
Capabilities:
Bit 0 : Leaf Router is a leaf node
Bit 1 : Prune Router understands pruning
Bit 2 : GenID Router sends Generation IDs
Bit 3 : Mtrace Router handles Mtrace requests
Bit 4 : SNMP Router handles SNMP requests
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 7
7
Source Address: 7 15 23 31
Source IP Address S of the Type Code
(S,G) to prune. Checksum
(0x13) (0x7)
Reserved Minor Major
Group Address:
Multicast Group address G of Source Address
the (S,G) to prune.
Group Address
Prune Lifetime:: Prune Lifetime
Time (in seconds) this prune
is active.
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 9
9
Group Address:
Multicast Group address G of the (S,G) to prune.
Prune Lifetime::
Time (in seconds) this prune is active.
7 15 23 31 7 15 23 31
Type Code Type Code
Checksum Checksum
(0x13) (0x8) (0x13) (0x9)
Reserved Minor Major Reserved Minor Major
Source Address Source Address
Group Address Group Address
Source Address:
Source IP Address S of the
(S,G) to graft.
Group Address:
Multicast Group address G of
the (S,G) to graft.
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 10
10
Group Address:
Multicast Group address G of the (S,G) to graft.
DVMRP Ask-Neighbors2
request for list of DVMRP Neighbors
(used by mrinfo)
DVMRP Neighbors2
response to above
(used by mrinfo)
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 11
11
DVMRP Ask-Neighbors
Used to request a list of all known Multicast neighbor routers. (This form of
the packet is obsolete and has been replaced by the
Ask-Neighbors2 packet.)
DVMRP Neighbors
Used to respond to the above Ask-Neighbors request. (This form of the
packet is obsolete and has been replaced by the Neighbors2 packet.)
DVMRP Ask-Neighbors2
This is the newer format of the Ask-Neighbors packet.
DVMRP Neighbors2
This is the newer format of the Neighbors packet.
7 15 23 31
Type Code
Checksum
(0x13) (0x5)
Reserved Minor Major
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 12
12
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 13
13
Local AddressN :
IP Address of a local interface.
MetricN :
Interface Metric
ThresholdN :
Metric-Threshold
FlagsN :
0 - Tunnel 3 - Down 6 - Leaf
1 - Src Route 4 - Disabled
2 - Reserved 5 - Reserved
Nbr CntN :
Number of Neighbors on this interface.
NbrX - NbrY :
List of Neighbor IP Addresses
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 14
14
2 3 Sends Probe
Receives Probe mrouted
from DVMRP Router 1 Neighbor List = 171.68.37.1
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 15
15
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 16
16
Initial State
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 17
17
2
Receives Route Report and updates entry
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 18
18
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 19
19
3) Router 1 sends its own DVMRP Route Report containing its routes to
Router 2. However, since Router 2 has a better metric for networks
151.10.0.0/16 and 204.1.16.0/24, it Poison Reverses these two routes by adding
32 to the metric.
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 20
20
4)Router 2 receives the DVMRP Route Report from Router 1 and performs
the following steps:
Adds network 198.14.32.0/24 to its DVMRP Route table (after incrementing
the received metric by 1).
Notes the fact that it received Poison Reverse advertisements for networks
151.10.0.0/16 and 204.1.16.0/24 from Router 1. This indicates that
Router 1 expects to receive multicast traffic for sources in these networks
from Router 2 (I.e Router 1 is a Child of Router 2 for these networks).
171.68.37.2
DVMRP Router 2
DVMRP Route Table
S0
Network Intf Metric mrouted
151.10.0.0/16 S0 3 5 Sends Route Report
E0
204.1.16.0/24 S0 10 151.10.0.0/16, M=3
198.14.32.0/24 E0 4 204.1.16.0/24, M=10
198.14.32.0/24, M=36
Poison
Reverse
Poison Reverse indicates
E0 DVMRP Route Table Router 2 is a Child
Network Intf Metric (Down-Tree) of Router 1
mrouted for these Sources
S0 151.10.0.0/16 S0
E0 6
4
DVMRP Router 1 198.14.32.0/24 S0 3
171.68.37.1 204.1.16.0/24 E0 11
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 21
21
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 22
22
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 24
24
mrouted mrouted
X
mrouted
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 25
25
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 26
26
X
RPF Check Fails!
mrouted S0 DVMRP Route Table
S1 Network IntfMetric
Intf Metric
mrouted 151.10.0.0/16 E1 4
E0 E1 198.14.32.0/24 S0 3
204.1.16.0/24 E0 11
Packet Arrived on
Wrong Interface!
mrouted mrouted
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 27
27
Packet Arrived on
Correct Interface!
mrouted mrouted
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 28
28
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 30
30
Receiver 1
(Group G)
DVMRP Pruning
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.
Receiver 1
(Group G)
Receiver 1
(Group G)
Receiver 1
(Group G)
mrouted mrouted
X
mrouted
Receiver 1
(Group G)
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 36
36
Receiver 1
(Group G) Receiver 2
(Group G)
Source Tree S Based on DVMRP Route Tables
(S, G) Multicast Packet Flow
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 37
37
DVMRP Grafting
Lets now assume that Receiver 2 now joins Group G by sending an IGMP
Host Membership report for group G to Router Y.
Router Y finds that it has state for source (S, G) and that it has previously
pruned the source from the Source Tree (show with dashed green arrows). As a
result, Router Y sends a Graft message to its upstream neighbor, Router E, for
source S.
DVMRP Grafting
Router E receives the Graft for (S, G) from Router Y and first responds by
sending a Graft-Ack message to acknowledge the receipt of Router Ys Graft
message.
Router E now finds that it too has previously pruned (S, G) from the Source Tree
and must therefore send an (S, G) Graft to its upstream neighbor Router D.
Receiver 1
(Group G) Receiver 2
(Group G)
Source Tree S Based on DVMRP Route Tables
(S, G) Multicast Packet Flow
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 39
39
DVMRP Grafting
Router D receives the Graft for (S, G) from Router E and first responds by
sending a Graft-Ack message to acknowledge the receipt of Router Es Graft
message.
Router D has not pruned (S, G) traffic from the Source Tree and therefore
simply adds the interface towards Router E to its outgoing interface list. This
restarts the flow of (S, G) traffic down to Receiver 2.
Neighbor discovery
Route exchange
Source trees
Multicast forwarding
Pruning
Grafting
Tunnels
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 40
40
mrouted
Non-Multicast
Network
Tunnel
Direct Connection
mrouted
Local Network
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 41
41
DVMRP Tunnels
DVMRP Tunnels are primarily used to tunnel through non-Multicast capable
networks.
DVMRP Tunnels also have the added benefit of reducing the hop count across
non-Multicast enabled networks to 1 hop. This is important when one considers
that infinity is 32 hops in DVMRP. Since the Internet is considerably more than
32 hops in diameter, DVMRP Tunnels are a necessity in the Internet.
mrouted
192.1.1.1
Module8. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 11:24 AM 42
42
DVMRP Tunnels
DVMRP Tunnels are implemented using IP-in-IP Encapsulation. This
encapsulation method uses an additional IP wrapper header with a protocol
number of 4. The IP wrapper header uses the IP addresses of the end points of
the tunnel as the Source and Destination addresses.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 1
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 2
Module Agenda
PIM-DVMRP Interoperability
Advanced PIM-DVMRP Features
Debugging Tips
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 3
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 4
176.32.10.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 5
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 6
w/Poison DVMRP
Reverse Reports*
Tunnel0 DVMRP
Prunes
DVMRP Unicast and Grafts
Route Route
Table E0 Table
PIM
Network
* Unicast routes advertised depends
on several factors
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 7
DVMRP
Reports* DVMRP DVMRP
E1 Prunes Grafts
IGMP
Unicast Group
Ignored Ignored
Route Joins**
E0 Table
RP
Border Router
Receiver,
Router A Router B Router C Group G
Mcst Cache Mcst Cache Mcst Cache
Empty (*,G) (*,G)
PIM-Sparse Mode
DVMRP
w/Poison
Reports*
Reverse
DVMRP DVMRP
E1 Prunes Grafts
Poison
Reverse RP
Border Router
(pre-11.2(13))
Receiver,
Router A Router B Router C Group G
Mcst Table Mcst Table Mcst Table
(S,G) (S,G) (S,G)
PIM-Sparse Mode
DVMRP
w/Poison
Reports**
Reverse
DVMRP DVMRP
E1 Prunes Grafts
Prune (S, G)
(S, G)
Traffic
Im not keeping
track of each DVMRP
neighbor. So I dont
Ignored
know if they have
ALL sent a Prune or
not??!!
Network S
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 13
13
DVMRP
Route
Ignored
Table
Networks
Si , Sj , Sk
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 14
14
DVMRP
w/Poison
Reports**
Reverse
DVMRP DVMRP
Prunes E1 Grafts
DVMRP Unicast
Route Route
Table E0 Table
* DVMRP neighbors tracked.
DVMRP Prunes supported.
PIM
** Unicast routes advertised Network
depends on several factors.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 15
15
Recommendations
OR
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 16
16
PIM-DVMRP Recommendation
Use IOS version 12.1 or later in order to more closely emulate the functions of a
DVMRP router and to avoid several of the issues discussed on the previous pages.
If this is not possible, the use of p2p links or DVMRP Tunnels is recommended in order
to avoid issues such as the Pruning issue.
Note: DVMRP Tunnels can be used across a multi-access link to avoid many of the
problems outline previously. This requires a separate DVMRP Tunnel to each
DVMRP router on the multi-access network. In addition, the PIM router and the
DVMRP router SHOULD disable multicast on this multi-access link and only permit
multicast traffic to flow via the DVMRP Tunnels.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 17
17
Tunnel
176.32.10.0/24 176.32.15.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 18
18
176.32.10.0/24 176.32.15.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 19
19
176.32.10.0/24 176.32.15.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 20
20
interface Tunnel 0
ip unnumbered Ethernet 0
DVMRP Report ip dvmrp summary-addr 176.32.0.0 255.255.0.0
151.16.0.0/16, M=39 ...
172.34.15.0/24, M=42 mrouted
202.13.3.0/24, M=40
176.32.0.0/16, M=1 Tunnel
176.32.10.0/24 176.32.15.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 21
21
176.32.10.0/24 176.32.15.0/24
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 22
22
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 23
23
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 24
24
RPF
Calculation
(Best Path)
BGP Route/Mask, Dist. (Use best
MRIB (eBGP Def. Dist.=20) Distance
(iBGP Def. Dist.=200) unless IIF, RPF Neighbor
Longest
DVMRP (Longest Match) Match1 is
Route/Mask, Dist. enabled.
Route
(Default Dist. = 0) If enabled,
Table
use longest
Mask.)
(Longest Match)
Unicast
Routing Route/Mask, Dist.
Table
1 Global Command: ip multicast longest-match
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 25
25
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 26
26
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 27
27
PIM-DVMRP Congruency
The source of RPF information normally should be consistent in all routers in the
network or the possibility of congruency problems can occur that result in multicast
traffic failing the RPF check in some routers.
The use of DVMRP routes can often cause these inconsistencies to occur if all routers
in the network are not maintaining DVMRP route tables. This can result in some routers
using the DVMRP route table for RPF calculations while the other routers are still using
the Unicast route table.
Physical Path
Tunnel Path
Data Flow
RPF Path
PIM-DM
MR1 MR2
Receiver Receiver
PIM-DVMRP Congruency
The slide above shows an example of how the use of DVMRP routes can cause RPF
failures as a result of Unicast/DVMRP incongruency.
Router MR2 is connected to a router in the DVMRP cloud via a DVMRP tunnel
over which it is receiving DVMRP routes for sources in the DVMRP network. Since
the default distance of DVMRP routes is zero, the DVMRP routes will be used by
MR2 to perform the RPF calculation for sources in the DVMRP cloud.
Multicast traffic from sources in the DVMRP cloud arrive via the DVMRP Tunnel and
pass the RPF check. (Based on the DVMRP Routing table in MR2 which RPFs up
the Tunnel.)
When the multicast traffic flow reaches router MR1, it does not have any DVMRP
routes and therefore uses the Unicast Route table to calculate the RPF interface
which is not the interface where the multicast traffic is arriving. As a result, the
multicast traffic fails the RPF check and is discarded.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 29
29
PIM/DVMRP Congruency
Avoid the use of DVMRP in your network if at all possible. However, this is sometimes
unavoidable when transitioning a legacy DVMRP network over to PIM.
The best solution is to maintain congruency between PIM routing and DVMRP routing.
Since PIM normally uses the unicast routing table for the RPF calculation, this means
that the DVMRP routing information would have to match the Unicast routing information
in order to make the topologies congruent. This is not always an option.
Another transition method is to propagate DVMRP routes to other routers in the PIM
domain to insure that the topologies remain congruent. This should only be considered
as a transition method since it may be necessary to propagate DVMRP routes to
EVERY router in the network in order to accomplish this.
MR3 PIM-DM
MR1 MR2
Receiver Receiver
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 30
30
PIM/DVMRP Congruency
In the example above, the DVMRP and PIM (Unicast) topologies are physically
congruent. This is because the DVMRP tunnel is terminated on router MR3 which
happens to also be the path out of the PIM domain. Hence, the RPF calculations done
on MR1 and MR2 (based on the unicast route table) will RPF correctly.
Receiver Receiver
ip dvmrp unicast-routing
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 31
31
PIM/DVMRP Congruency
In the example above, the DVMRP and PIM (unicast) topologies are not physically
congruent on routers MR1 and MR3. This is because the DVMRP tunnel is terminated
further down inside of the PIM domain. (In this case, it is terminated on MR2). As a
result, router MR1 would normally have an RPF path (for sources outside the PIM
domain) via router MR3. This would cause RPF failures at router MR1 for arriving traffic
received via router MR2 and the DVMRP tunnel.
A transition strategy would be to have MR2 and MR1 exchange DVMRP routes using
the ip dvmrp unicast-routing command. This will permit MR2 to send DVMRP routes to
MR1 which will in turn, result in MR1 using these routes to RPF for sources in the
DVMRP network.
Note: It would also be necessary to exchange DVMRP routes from MR1 to MR3 if
there are any other interfaces (not shown) on MR3 where there are hosts or PIM
neighbor routers. Otherwise, MR3 would also RPF fail any traffic arriving from
MR1.
DVMRP Unicast
PIM Router Route Route
Table Table
*Split-Horizon is used between
two PIM neighbors instead of
Poison Reverse.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 32
32
mrouted
RPF Direction
Mcst Traffic
X
X X
RPF Failures!!!
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 33
33
mrouted
Solution 1:
Terminate tunnel at top of
RPF Direction
hierarchy.
Mcst Traffic
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 34
34
mrouted
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 36
36
PIM-DM/DVMRP Boundaries
DVMRP is a dense mode protocol which uses the Push model to flood traffic to all
points in the network. (Routers that dont have receivers for the traffic will then Prune
the traffic flow.)
PIM-DM uses the same Push model to Flood-and-Prune traffic to all parts of the
network.
Because the two protocols use the same basic Push model, traffic can be flooded
across the PIM-DM/DVMRP boundary without using any complex mechanisms.
The PIM -DM boundary router will use the DVMRP Poison-Reverse mechanism as
well as normal DVMRP Prunes and Grafts to maintain traffic flow between the two
networks.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 38
38
PIM-DM/DVMRP Boundaries
Traffic sourced from sources in the DVMRP cloud:
When the first packet arrives from source S in the DVMRP cloud at the PIM-DM
router, the router will create (S,G) state using the normal PIM -DM state creation
rules.
The incoming interface for the (S,G) entry will be computed and assuming that a
route exists for this source in the DVMRP routing table (it should since the PIM
router is receiving DVMRP routes), the Incoming Interface will point to the DVMRP
neighbor.
Packets arriving from the DVMRP neighbor will now RPF correctly and be flooded
out all other interfaces on the PIM-DM router where there are other PIM -DM
neighbors. This permits the push model to work across the boundary from the
DVMRP network towards the PIM network.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 39
39
PIM-DM/DVMRP Boundaries
Traffic sourced from sources in the PIM-DM cloud:
When the first packet arrives from source S in the PIM-DM cloud at the
PIM/DVMRP border router, the router will create (S,G) state using the normal PIM -
DM state creation rules.
In addition, if the border router has received a DVMRP Poison-Reverse route for
this particular source network, the border router will add the DVMRP neighbors
interface to the outgoing interface list of the (*, G) and (S,G) forwarding entry. If a
Prune message is received from all DVMRP neighbors on this interface, the PIM
router will Prune the interface in the (S, G) outgoing interface list.
The incoming interface for the (S,G) entry will be computed based on the unicast
routing table resulting in the Incoming Interface pointing to the PIM -DM neighbor in
the direction of the source in the PIM cloud.
Packets arriving from this PIM-DM neighbor will now RPF correctly and be flooded
out all interfaces in the (S, G) outgoing interface list including the interface on which
the DVMRP neighbor resides. This permits the push model to work across the
boundary from the PIM network towards the DVMRP network.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 40
40
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 41
41
PIM-SM/DVMRP Boundaries
DVMRP is a dense mode protocol which uses the Push model to flood traffic to all
points in the network. (Routers that dont have receivers for the traffic will then Prune
the traffic flow.)
PIM-SM uses the Pull model to forward traffic to only those parts of the network where
it has been explicitly requested.
Because DVMRP is using the Push model, while the PIM-SM network is using the
Push model, special considerations must be used to get traffic to flow across the PIM-
DM/DVMRP boundary.
The PIM -SM/DVMRP solution requires the use of the Receiver-is-a-Sender hack
in order to get traffic to flow across the PIM-SM/DVMRP boundary.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 42
42
PIM-SM/DVMRP Boundaries
Traffic sourced by sources in the DVMRP cloud.
Since the DVMRP cloud uses the Push model, multicast traffic will be flooded to all
points in the network including the PIM-SM/DVMRP border.
When the first packet arrives from source S in the DVMRP cloud at the PIM-SM
router, the router will create (S,G) state using the normal PIM -SM state creation
rules.
The incoming interface for the (S,G) entry will be computed and assuming that a
route exists for this source in the DVMRP routing table (it should since the PIM
router is receiving DVMRP routes), the Incoming Interface will point to the DVMRP
neighbor.
The PIM -SM border router will then Register this traffic to the RP as if it was
coming from a directly connected source. This will ultimately result in the traffic
flowing to the RP and on down the Shared Tree to any interested receivers for
group G traffic in the PIM -SM network.
The PIM -SM border router will also include the DVMRP neighbors interface in the
(*,G) outgoing interface list and trigger a (*,G) Join toward the RP to build a branch
of the Shared Tree. This causes any traffic being sent by sources in the PIM-SM
network to flow down the Shared Tree to the PIM border router and be forwarded to
the DVMRP router.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 43
43
PIM-SM/DVMRP Boundaries
Traffic sourced by sources in the PIM-SM cloud.
Since the DVMRP cloud uses the Push model instead of the Pull model, the
DVMRP border router has no way of knowing if there are any receivers in the
DVMRP network and therefore cannot inform the PIM-SM router of this fact.
As a result of the differences in these two models, the only way to insure that traffic
flows from PIM-SM network to the DVMRP network is by using the Receiver-is-a-
Sender hack. This hack relies on the receiver to first send multicast traffic to the
group. This traffic will be flooded to the PIM-SM/DVMRP border and will cause the
border router to join the Shared Tree for the group. (See explanation on the
previous page.)
Once a branch of the Shared Tree is setup, any traffic being sent by sources in the
PIM-SM network can then flow down the Shared Tree to the PIM border router and
be forwarded to the DVMRP router.
Tunnel0 RP
Source S1,
Group G
Router A Router B Router C
Mcst Table Mcst Table Mcst Table
NULL (*, G) (*, G)
(S1 , G) (S1 , G) PIM-Sparse Mode
Border Router
RP
Tunnel0
Source S1,
Router A Router B Router C Group G
Mcst Table Mcst Table Mcst Table
NULL (*, G) (*, G)
(S1 , G) (S1 , G) PIM-Sparse Mode
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 45
45
Solution 1:
One of the easiest solutions to this problem is to always terminate the DVMRP tunnel
(or border) on the RP.
This will cause any traffic sent by sources in the PIM-SM cloud to flow to the RP
(using normal PIM-SM forwarding rules) and then be flooded across the interface
to the DVMRP neighbor.
Unfortunately, this solution is not always possible as there may be multiple
candidate RPs in the network or other network topology issues may preclude this
approach.
Solution 2:
Another possible (but rather ugly) solution is to use PIM-DM to extend the dense mode
flooding from the RP to the DVMRP neighbor.
This has some very obvious drawbacks including dense-mode flooding across
potentially large portions of the network if the distance from the RP to the border are
great.
Tunnel0 RP
Source S1,
Router A Router B Router C Group G
Solution 3:
The most often used solution is to employ the Receiver-is-a-Sender hack.
This solution normally works well for legacy multicast applications such as the
Mbone multimedia conferencing applications (vic, vat, rat, wb, etc.) since these
applications always send back-channel RTCP traffic to the multicast group.
Unfortunately, this solution can not be used reliably for applications that are truly
Receive-only.
PIM-DVMRP Interoperability
Advanced PIM-DVMRP Features
Debugging Tips
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 48
48
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 49
49
Route Redistribution
By default, only Connected routes are advertised by a router in DVMRP route updates.
This behavior can be overridden with the following interface command:
DVMRP Cloud
mrouted mrouted
PIM Cloud
ip dvmrp unicast-routing
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 50
50
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 51
51
Note: DVMRP Probes are also ignored from any DVMRP neighbors that are denied
(either explicitly or implicitly) by The neighbor-list ACL. This feature can be used to
disable the automatic PIM-DVMRP interoperability on an interface by configuring a
deny all ACL for the neighbor-list.
ip dvmrp metric-offset [in | out] <increment>
This interface command can be used to offset the metrics of the incoming or outgoing
DVMRP route updates by the amount specified by <increment>.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 52
52
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 53
53
Note: This is very useful when connecting to DVMRP stub networks as it saves on the
amount of bandwidth and routing state consumed in the stub network router(s).
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 54
54
Summary Origination
Classful summarization is on by default for DVMRP. This means that subnets from a
network that are different than the network number of the interface will be automatically
summarized into their classful summarization. This behavior may be disabled using the
following command:
no ip dvmrp auto-summary
This interface command turns off the classful summarization of routes across an
interface.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 55
55
Summary Origination
ip dvmrp summary-address <address> <mask> metric <metric>
This interface command configures a summary address to be advertised out the
interface. If there is at least one more specific route in the unicast routing table that
matches the <address>/<mask>, the summary will be advertised. (Note: Routes in the
DVMRP routing table are not candidates for summarization.)
When the metric keyword is supplied, the summary will be advertised with the metric
specified by <value>. The default metric <value> is 1.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 56
56
This command is necessary so misconfigured "ip dvmrp metric" commands don't cause
massive route injection into the MBONE. The "no" version of the command configures
no limit. [11.0]
ip dvmrp routehog-notification <route-count>
This global command configures the number of routes allowed within an approximate
one minute interval before a syslog message is isssued warning that there maybe a
route surge going on in the MBONE. This is typically used to detect quickly when
someone has misconfigured their routers to inject a large number of routes into the
MBONE. The default value is 10,000. You can find a running count in the "show ip igmp
interface" display. When the count is exceeded, you'll see an "*** ALERT ***" string
appended to the line. [10.2]
ip dvmrp reject-non-pruners
This interface command will cause the router not to peer with a DVMRP neighbor if the
neighbor doesn't support DVMRP Pruning/Grafting. This command was added so that
the policy of no-support for non-Pruning DVMRP versions could be enforced in the
Internet.
PIM-DVMRP Interoperability
Advanced PIM-DVMRP Features
Debugging Tips
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 57
57
interface ethernet1
135.1.2.100 ip addr 135.1.2.102 255.255.255.0
ip pim dense-mode
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 58
58
Example Network
The network shown in the above drawing will be used through-out this section on
debugging tips. Take particular note of Tunnel0 source and destination addresses as
well as the address of the host workstation. These addresses will be important in the
upcoming pages.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 59
59
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 60
60
pim -dvmrp
pim- dvmrp--gw
gw>>mrinfo 135.1.22.98
135.1.22.98 [version mrouted 3.8] [flags: GPM]: Both Ends See
172.21.32.98 -> 172.21.32.191 [1/1] Each Other
172.21.32.98 -> 172.21.32.1 [1/1]
135.1.22.98 -> 135.1.22.102 [1/1/querier
[1/1/querier]]
135.1.22.98 -> 135.1.3.102 [1/1/tunnel]
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 61
61
We are looking for the tunnel interface status from the Cisco gateway router to the
DVMRP router at the other end of the tunnel. This is shown on the line that reads:
The key item to look for is the absence of the word down in the status. This
indicates that the tunnel is up in the direction from the Cisco to the DVMRP router.
In the second example above, the mrinfo command is entered on the PIM-DVMRP
gateway router with the IP address of the DVMRP router. (I.e the tunnel destination
address, 135.1.22.98.) This causes the DVMRP router at the other end of the
tunnel to report back its multicast interface status information.
We are looking for the tunnel interface status from the DVMRP router at the other
end of the tunnel back toward the Cisco gateway router. This is shown on the line
that reads:
Again, the key item to look for is the absence of the word down in the status. This
indicates that the tunnel is up in the direction from the DVMRP router to the Cisco
gateway router.
Since both ends of the tunnel are up (i.e. neither is displaying down), the tunnel is
up in both directions.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module9.ppt 61
Debugging Tips
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 62
62
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 64
64
Note: The 8 DVMRP routes being sent are actually Poison Reverse routes for the 8
DVMRP routes received from the DVMRP neighbor. The 2 unicast routes are local
unicast routes (in this case the directly connected networks on the Cisco gateway
router) that are being advertised to the DVMRP neighbor in the DVMRP Report.
However, this information is not obvious unless we turn on more debugging detail.
In the second highlighted section, we see that the Cisco gateway router has
received a DVMRP Report via Tunnel0 from the DVMRP neighbor, 135.1.22.98.
Unfortunately, with this level of debug we do not know how many routes were
contained in the Report.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 65
65
Notice that the 8 DVMRP routes have a metric greater than 32 (infinity) which
indicates that these routes are Poison-Reverse routes. The two unicast routes
being advertised in this DVMRP report are highlighted in the above example. Notice
that these are the two connected networks on the Cisco gateway router. (Refer to
the Example network drawing in a previous slide.)
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 66
66
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 67
67
Note: Assumes SDR is being used in the old DVMRP cloud to announce sessions.
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 68
68
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 69
69
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 71
71
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 72
72
Module9.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 2:11 PM 73
73
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 1
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 2
2
BGP Review
MBGP Overview
MBGP Update Messages
MBGP Capability Negotiation
MBGP NLRI Information
Advanced MBGP Features
New 12.1 MBGP Syntax
Debugging MBGP
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 3
3
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 4
4
A C
AS 100 AS 101
220.220.8.0/24 220.220.16.0/24
B D
BGP speakers E
are called peers
AS 102
Peers in different ASs
220.220.32.0/24
are called External Peers
eBGP TCP/IP
Peer Connection
Note: eBGP Peers normally should be directly connected.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 5
5
A C
AS 100 AS 101
220.220.8.0/24 220.220.16.0/24
B D
A C
AS 100 AS 101
220.220.8.0/24 220.220.16.0/24
B D
Information (NLRI)
BGP Update
Messages
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 7
7
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 8
8
AS 100 AS 101
iBGP TCP Connection
222.222.10.0/30
A .2 220.220.8.0/24 .1 B .2 .1 C .2 220.220.16.0/24 .1 D
AS 100
B
A
iBGP TCP/IP
Peer Connection
C
AS 100 215.10.7.2
215.10.7.1
B
A
215.10.7.3
iBGP TCP/IP
Peer Connection
C
AS 100 215.10.7.2
215.10.7.1
B
A
215.10.7.3
iBGP TCP/IP
Peer Connection
interface loopback 0
ip address 215.10.7.1 255.255.255.255
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 12
12
AS 100 215.10.7.2
215.10.7.1
B
A
215.10.7.3
iBGP TCP/IP
Peer Connection interface loopback 0
ip address 215.10.7.2 255.255.255.255
C
router bgp 100
network 220.220.5.0
neighbor 215.10.7.1 remote-as 100
neighbor 215.10.7.1 update-source loopback0
update-
neighbor 215.10.7.3 remote-as 100
neighbor 215.10.7.3 update-source loopback0
update-
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 13
13
AS 100 215.10.7.2
215.10.7.1
B
A
215.10.7.3
iBGP TCP/IP
Peer Connection
interface loopback 0 C
ip address 215.10.7.3 255.255.255.255
Prefix (Variable)
Unfeasible Routes Length (2 Octets)
Prefix (Variable)
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 16
16
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 17
17
BGP Attributes
Attributes are associated with the NLRI (i.e. the route) being advertised. These
attributes include (but are not limited to) the following:
AS path
Next-Hop
Local Preference
Multi-Exit Discriminator (MED)
Community
Origin
Aggregator
The discussion of all of these attributes is beyond the scope of this tutorial.
However, the AS-Path and Next-Hop attributes are discussed in the following
sections since they are fundamental to the basic operation of BGP.
Network Path
AS 500 180.10.0.0/16 300 200 100
170.10.0.0/16 300 200
150.10.0.0/16 300 400
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 18
18
AS-Path Attribute
This attribute describes the sequence of AS numbers that must be traversed to
reach the network whose prefix is advertised in the NLRI field of the Update
message. As each eBGP speaker in the network forwards this Update message
on to its eBGP neighbors, the local AS number is prepended to this AS-Path list.
In the above example, network 180.10.0.0/16 resides inside of AS100. Notice
that after this network prefix is reaches AS 500, the AS-Path for network
180.10.0.0/16 is 300 200 100. This means that traffic destined for this network
must travel to AS 300, then on to AS 200 and finally AS 100 where network
180.10.0.0 resides.
The same thing occurs for networks 170.10.0.0/16 and 150.10.0.0/16. An
Update messages are originated by AS 200 and AS 400, respectively. When
these Update messages reach AS 500, a separate entry is maintained for each
network along with its unique AS-Path.
AS 300
AS 200 192.10.1.0/30 140.10.0.0/16
150.10.0.0/16 C .1 .2 D
E
B
BGP Update .2
Network Next-Hop Path
/30
.2.0
.1
Next hop to reach a network
A
Usually a local network is the next
AS 100 hop in eBGP session
160.10.0.0/16
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 19
19
Next-Hop Attribute
The Next-Hop attribute contains the IP address of the next-hop router to which
traffic destined for the network specified in the NLRI is to be sent. This is
normally a directly connected network in the case of eBGP sessions.
In the above example, network 160.10.0.0/16 resides in AS 100. Router A
originates an Update message containing this network in the NLRI and sends
this to Router B as shown. The Next-Hop attribute in the Update message
contains the the IP address of Router As serial port, namely 192.20.2.1. This
information instructs Router B that traffic for network 160.10.0.0/16 should be
sent to 192.20.2.1 (Router A) for forwarding on to the destination.
AS 300
AS 200 192.10.1.0/30 140.10.0.0/16
150.10.0.0/16 C .1 .2 D
E
B
BGP Update /30 .2 Network Next-Hop Path
150.10.0.0/16 192.10.1.1 200
.2.0
Messages
160.10.0.0/16 192.10.1.1 200 100
.20
192
.1
Next hop to reach a network
A
Usually a local network is the next
AS 100 hop in eBGP session
160.10.0.0/16 Next Hop updated between
eBGP Peers
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 20
20
Next-Hop Attribute
The Next-Hop attribute is normally updated with the local IP address of the
eBGP router when an Update message is forwarded to another eBGP peer.
In the above example, the Update for network 160.10.0.0/16 is being forwarded
by Router C to its eBGP peer Router D. Notice that the Next-Hop attribute in
the Update message has been updated to contain the the IP address of Router
Cs serial port, namely 192.10.1.1. This information instructs Router D that traffic
for network 160.10.0.0/16 should be sent to 192.10.1.1 (Router C) for forwarding
on to the destination.
AS 300
AS 200 192.10.1.0/30 140.10.0.0/16
150.10.0.0/16 C .1 .2 D
E
B
BGP Update .2
Network Next-Hop Path
/30
.2.0
.1
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 21
21
Next-Hop Attribute
The Next-Hop attribute is not updated when the Update message is being sent
to an iBGP peer.
In the above example, the Update for network 160.10.0.0/16 is being forwarded
by Router D to its iBGP peer Router E. Notice that the Next-Hop attribute for
network 160.10.0.0/16 has not been updated and still contains the the IP
address of Router Cs serial port, namely 192.10.1.1. This means that the IGP
running in AS 300 must contain routing information for 192.10.1.1 so that Router
E can resolve how to forward the traffic for network 160.10.0.0/16 across AS 300
to Router D.
Note: The requirement of carrying this Next-Hop information through the
IGP (in this case a route to 192.10.1.1) can be eliminated by the use of the
next-hop-self command at Router D. This forces Router D to update the
Next-Hop attribute with its own IP address when sending the Update to its
iBGP neighbor, Router E.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 22
22
Next-Hop Attribute
In general, the IGP should carry a route to the Next-Hop address as these
addresses are often outside the address space in the IGP.
iBGP speakers must perform a recursive route lookup to resolve the BGP
Next-Hop information to a local IGP next-hop. (In other words, the iBGP
router must determine the internal network next hop in the direction of iBGP
speaker on the other side of the AS that advertised the network.
This uncouples BGP from the actual physical topology of the network inside
of the AS. As long as the IGP can find a path through the network to reach
the Next-Hop address, then transient traffic can be routed across the AS to
the exit-point iBGP router.
This also permits the IGP to make intelligent forwarding decisions based on
the internal metrics set in the local network.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 23
23
Withdrawn Routes
This section of the Update message contains zero or more routes (prefix) that
are to be withdrawn. The message is used to inform a BGP neighbor that the
specified routes are no longer reachable.
AS 321
AS 123
.1 192.168.10.0/24 .2
BGP Update
Message
Withdraw Routes
192.192.25.0/24
x
Connectivity lost 192.192.25.0/24
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 24
24
Withdrawn Routes
In this example, network 192.192.25.0/24 was previously advertised to AS 123.
However, the only interface to this network has failed. As a result, an Update
message is sent to AS 123 with the prefix of network 192.192.25.0/24 in the
Withdrawn Routes section of the message. The eBGP peer in AS 123 will
update the information in its BGP Routing Information Base (RIB) to mark this
route as withdrawn.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 25
25
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 26
26
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 27
27
BGP in process
receives path information from peers
results of BGP path selection placed in the BGP table
best path flagged (denoted by >)
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 28
28
Network
Network Next-Hop
Next-Hop Path
Path
160.10.1.0/24
160.10.1.0/24 192.20.2.2
192.20.2.2 200
200
160.10.3.0/24
160.10.3.0/24 192.20.2.2
192.20.2.2 200
200
173.21.0.0/16
173.21.0.0/16 192.20.2.2
192.20.2.1
192.20.2.2 200
200 100
100
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 29
29
D 10.1.2.0/24
D 160.10.1.0/24 Best paths installed in routing table if:
D 160.10.3.0/24
R 153.22.0.0/16 prefix and prefix length are unique
S 192.1.1.0/24 lowest protocol distance
B 173.21.0.0/16
Route Table
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 30
30
MBGP Overview
MBGP Update Messages
MBGP Capability Negotiation
MBGP NLRI exchange
MBGP-DVMRP redistribution
BGP-to-MBGP redistribution
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 31
31
MBGP Overview
Multiprotocol BGP (MBGP) is defined in RFC 2283. This RFC defines
extensions to the existing BGP protocol to allow it to carry more than just IPv4
route prefixes. Examples of some of the new types of routing information
include (but are not limited to):
IPv4 prefixes for Unicast routing
IPv4 prefixes for Multicast RPF checking
IPv6 prefixes for Unicast routing
A common misconception is that MBGP is a replacement for PIM. This is
incorrect. MBGP does not propagate any multicast state information nor does it
build any sort of multicast distribution trees. MBGP can distribute unicast
prefixes that can be used for the multicast RPF check.
Because MBGP is an extension to the existing BGP protocol, the same basic
rules apply to path selection, path validation, etc.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 34
34
Prefix (Variable)
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 35
35
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 36
36
MP_REACH_NLRI Attribute
The key characteristics of this new attribute is the Address Family Identifier and
Sub-Address Family Identifier fields. These two fields define the type of routing
information that is carried in the NLRI field of this attribute.
The Next-Hop Address information is contained in the field following the AFI and
Sub-AFI fields.
Following the Next-Hop Address fields are zero or more SNPA fields. These
field contain the attributes associated with the NLRI field. (For IPv4 AFIs, these
attributes are the same as the old style BGP attributes.)
Finally, the NLRI field contains the Length and Prefix information of the route
that is being advertised as reachable.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 37
37
MP_UNREACH_NLRI Attribute
Address Family Identifier (2 Octets)
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 38
38
MP_UNREACH_NLRI Attribute
This new attribute permits unfeasible routes of the new protocol types to be
withdrawn in the same fashion as the Withdrawn Routes field is used in BGP.
Notice that this attribute also carries the AFI and Sub-AFI fields along the
associated Length and Prefix of the withdrawn route.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 40
40
AS 321
AS 123
.1 192.168.100.0/24 .2
Receiver
Sender
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 41
41
AS 321
AS 123
.1 192.168.100.0/24 .2
Receiver
Sender
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 42
42
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 43
43
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 44
44
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 45
45
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 46
46
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 47
47
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 48
48
Redistribution commands
router bgp 100
redistribute <unicast> [<process>] route-map foo
access-list 1 permit 192.10.0.0 0.0.255.255
route-map foo permit 10
match ip address 1
set nlri multicast
Route map set nlri clause controls which RIB the
matching route(s) is(are) stored
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 49
49
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 50
50
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 51
51
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 52
52
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 53
53
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 54
54
Congruent Topologies
BGP Session for Unicast and AS 321
AS 123 Multicast NLRI
.1 192.168.100.0/24 .2
Receiver
Sender
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 56
56
Congruent Topologies
BGP Session for Unicast and AS 321
AS 123 Multicast NLRI
.1 192.168.100.0/24 .2
Receiver
Sender
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 57
57
Congruent Topologies
BGP Session for Unicast and AS 321
AS 123 Multicast NLRI
.1 192.168.100.0/24 .2
Unicast Information
NLRI: 192.192.25/24
AS_PATH: 321
MED:
Next-Hop: 192.168.100.2
192.168.10.0/24
...
192.192.25.0/24
Multicast Information
MP_REACH_NLRI: 192.192.25/24
Receiver
AFI: 1, Sub-AFI: 2 (multicast) Sender
AS_PATH: 321
MED:
Next-Hop: 192.168.100.2
...
Routing Update
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 58
58
Congruent Topologies
BGP Session for Unicast and AS 321
AS 123 Multicast NLRI
.1 192.168.100.0/24 .2
Unicast Information
NLRI: 192.168.10/24
AS_PATH: 123
MED:
192.168.10.0/24 Next-Hop: 192.168.100.1
...
192.192.25.0/24
Multicast Information
Routing Update
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 59
59
Incongruent Topologies
AS 321
AS 123
.1 Unicast Traffic 192.168.100.0/24 .2
.1 Multicast Traffic .2
192.168.200.0/24
192.192.25.0/24
192.168.10.0/24
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 60
60
Incongruent Topologies
AS 321
AS 123
.1 Unicast Traffic 192.168.100.0/24 .2
.1 Multicast Traffic .2
192.168.200.0/24
192.192.25.0/24
192.168.10.0/24
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 61
61
Incongruent Topologies
AS 321
AS 123
.1 Unicast Traffic 192.168.100.0/24 .2
.1 Multicast Traffic .2
192.168.200.0/24
192.192.25.0/24
192.168.10.0/24
Sender
Unicast Information
NLRI:
NLRI: 192.192.25/24
192.192.25/24
AS_PATH:
AS_PATH: 321321
MED:
MED:
Next-Hop: 192.168.100.2
Next-Hop: 192.168.100.2
Routing Update
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 62
62
Incongruent Topologies
AS 321
AS 123
.1 Unicast Traffic 192.168.100.0/24 .2
.1 Multicast Traffic .2
192.168.200.0/24
192.192.25.0/24
192.168.10.0/24
Sender
Multicast Information
MP_REACH_NLRI:
MP_REACH_NLRI: 192.192.25/24
192.192.25/24
AFI:
AFI: 1,
1, Sub-AFI:
Sub-AFI: 22
AS_PATH:
AS_PATH: 321321
MED:
MED:
Next-Hop:
Next-Hop: 192.168.200.2
192.168.200.2
Routing Update
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 63
63
Incongruent Topologies
AS 321
AS 123
.1 Unicast Traffic 192.168.100.0/24 .2
.1 Multicast Traffic .2
192.168.200.0/24
192.192.25.0/24
192.168.10.0/24
Sender
Unicast RIB
Network Next-Hop Path
192.192.25.0/24 192.168.100.2 321
Multicast RIB
Network Next-Hop Path
192.192.25.0/24 192.168.200.2 321
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 64
64
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 65
65
Use command
neighbor <foo> translate-update [nlri multicast]
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 66
66
NLRI:
NLRI: 192.192.2/24
192.192.2/24 NLRI:
NLRI: 192.192.2/24
192.192.2/24
AS_PATH:
AS_PATH: 300
300 200
200 AS_PATH:
AS_PATH: 300
300 200
200
MED:
MED: MED:
MED:
Next-Hop:
Next-Hop: 192.168.200.2
192.168.200.2 Next-Hop:
Next-Hop: 192.168.200.2
192.168.200.2
MP_REACH_NLRI:
MP_REACH_NLRI: 192.192.2/24
192.192.2/24
AFI:
AFI: 1,
1, Sub-AFI:
Sub-AFI: 22 (multicast)
(multicast)
AS_PATH:
AS_PATH: 300
300 200
200
MED:
MED:
Next-Hop:
Next-Hop: 192.168.200.2
192.168.200.2
Unicast /
AS 2
Unicast NLRI Only Multicast
Stub AS NLRI AS LO0 192.170.1.1 Unicast /
Multicast
NLRI AS
.1 .2
AS 4 192.168.1.0/24 AS 1
192.192.25.0/24
router bgp 1
. . .
neighbor 192.168.1.1 remote-as 4
neighbor 192.168.1.1 translate-
translate-update nlri multicast
AS 3 Unicast /
neighbor 192.170.1.1 remote-as 2 nlri unicast multicast Multicast
neighbor 192.180.1.1 remote-as 3 nlri unicast multicast
. . . LO0 192.180.1.1 NLRI AS
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 68
68
Unicast /
AS 2
Unicast NLRI Only Multicast
Stub AS NLRI AS LO0 192.170.1.1 Unicast /
Multicast
NLRI AS
.1 .2
AS 4 192.168.1.0/24 AS 1
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 69
69
Unicast /
AS 2
Unicast NLRI Only Multicast
Stub AS NLRI AS LO0 192.170.1.1 Unicast /
Multicast
NLRI AS
.1 .2
AS 4 192.168.1.0/24 AS 1
192.192.25.0/24
AS 3 Unicast /
Multicast Updates Multicast
MP_REACH_NLRI: 192.192.25/24 LO0 192.180.1.1 NLRI AS
AFI: 1, Sub-AFI: 2 (multicast)
AS_PATH: 1, 4
MED:
Next-Hop:
...
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 70
70
Unicast /
AS 2
Unicast NLRI Only Multicast
Stub AS NLRI AS LO0 192.170.1.1 Unicast /
Multicast
NLRI AS
.1 .2
AS 4 192.168.1.0/24 AS 1
192.192.25.0/24
AS 3 Unicast /
Unicast Updates Multicast
NLRI: 192.192.25/24 LO0 192.180.1.1 NLRI AS
AS_PATH: 1, 4
MED:
Next-Hop:
...
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 71
71
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 72
72
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 73
73
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 74
74
AS 2
LO0 192.170.1.1
DVMRP Tunnel
AS 1
DVMRP Stub
Network
router bgp 1
neighbor 192.168.1.1 remote-as 4
neighbor 192.170.1.1 remote-as 2 nlri unicast multicast AS 3
neighbor 192.180.1.1 remote-as 3 nlri unicast multicast
redistribute dvmrp route-
route -map dvmrp-
dvmrp-to
to-
-mbgp
access-list 1 permit 192.168.0.0 0.0.255.255
access-
LO0 192.180.1.1
route-
route-map dvmrp-
dvmrp-to
to--mbgp permit 10
match ip address 1
set nlri multicast
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 75
75
AS 2
LO0 192.170.1.1
DVMRP Tunnel
AS 1
DVMRP Stub
Network
DVMRP Report
Route Metric AS 3
192.168.0.0/16 14
LO0 192.180.1.1
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 76
76
AS 2
LO0 192.170.1.1
DVMRP Tunnel
AS 1
DVMRP Stub
Network
AS 3
Multicast Updates
MP_REACH_NLRI: 192.168/16 LO0 192.180.1.1
AFI: 1, Sub-AFI: 2 (multicast)
AS_PATH: 1, 4
MED:
Next-Hop:
...
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 77
77
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 78
78
MBGP History
Introduced in IOS 12.0S
nlri clause added to BGP syntax
Covered IPv4 Unicast and Multicast NLRI only
Didnt cover other protocols or address-families
Extending nlri syntax considered
Rejected as being too inflexible
New syntax as of 12.1/12.0(7)T
Exception: 12.0S train retains old syntax
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 79
79
MBGP History
Support for Multiprotocol BGP was first introduced in IOS release 12.0S. In
order to support different types of NLRI exchange, the nlir clause was added to
many of the existing BGP configuration commands. However, this initial release
only supported ipv4 unicast and ipv4 multicast NLRI.
In order to support other types of NLRI, (such as IPv6) it was decided that the
nlri syntax was not suitable and a new change in the syntax was introduced
beginning in IOS releases 12.1 and 12.0(7)T.
The 12.0S train still retains the old syntax.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 80
80
Address-family structure
In order to support different types of address-family and sub-address family
NLRI, the address-family block was added to the BGP configuration command
syntax.
The address-family block replaces many of the old nlri clauses. However,
there are still some commands that retain the use of the nlri keyword.
The address-family block is used to separate groups of configuration commands
by address-family/sub-address family.
In order to remain as backwards compatible as possible, the default address
family is ipv4 unicast. This results in an implied address-family ipv4 unicast
block.
This default behavior is sometimes confusing because it merges common
bgp configuration commands with ipv4 unicast specific commands. In
addition, neighbor definition implies ipv4 unicast capability negotiation by
default. This makes specifying ipv4 multicast only neighbors a bit
confusing.
The no bgp default ipv4-unicast command may be used to override this
rather confusing behavior. When this command has been configured, a
separate address-family ipv4 unicast block can be configured. This allows
the configuration to clearly separate ipv4 unicast and multicast into separate
address-family blocks.
Address-Family Example:
router bgp 101
no synchronization
bgp log-neighbor-changes
network 172.16.21.0 mask 255.255.255.0
Implied ipv4 unicast network 192.168.1.0
address family block neighbor 172.16.1.2 remote-as 301
with implied neighbor neighbor 172.16.11.2 remote-as 201
activate commands no neighbor 172.16.11.2 activate
no auto-summary
!
address-family ipv4 multicast
neighbor 172.16.11.2 activate
Explicit ipv4 multicast
network 172.16.21.0 mask 255.255.255.0
address family block
network 192.168.1.0
exit-address-family
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 82
82
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 83
83
After Conversion
router bgp 5
network 171.69.214.0 mask 255.255.255.0
neighbor 171.69.214.38 remote-as 2
neighbor 171.69.214.50 remote-as 2
no neighbor 171.69.214.50 activate Overrides implied neighbor activate
! for the ipv4 unicast address family
address-family ipv4 multicast
neighbor 171.69.214.50 activate
network 171.69.214.0 mask 255.255.255.0
exit-address-family
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 84
84
router bgp 5
network 171.69.214.0 mask 255.255.255.0 nlri unicast multicast
neighbor 171.69.214.38 remote-as 2 nlri unicast
neighbor 171.69.214.50 remote-as 2 nlri multicast
After the conversion, the configuration has the implied ipv4 address block in the
top lines as follows:
router bgp 5
network 171.69.214.0 mask 255.255.255.0
neighbor 171.69.214.38 remote-as 2
neighbor 171.69.214.50 remote-as 2
no neighbor 171.69.214.50 activate
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 85
85
Syntax Tricks
By using the no bgp default ipv4-unicast command, we can disable the
default, implied ipv4 unicast address family block and its implied neighbor
activation commands. (Which can be quite confusing in a multiprotocol
envirionment.)
When this command is configured, it allows a clear separation of ipv4
unicast and multicast configurations commands. In addition, activate
commands must be explicitly configured in each section.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 87
87
Debugging MBGP
The above command may be used to debug the status of a (M)BGP peer
connection with a neighbor. Notice that the highlighted text indicates exactly
what capabilities and NLRI are being exchanged between the router and this
peer.
Note: If the Neighbor NLRI negotiation field is missing, only unicast NLRI
information is being exchanged.
Network
Network Next
Next Hop
Hop Metric
Metric LocPrf
LocPrf Weight
Weight Path
Path
*>10.0.100.0/24
*>10.0.100.0/24 0.0.0.0
0.0.0.0 00 32768
32768 ii
show ip mbgp
asimov#
asimov# show
show ip
ip mbgp
mbgp
MBGP
MBGP table
table version
version isis 6,
6, local
local router
router ID ID is
is 10.0.100.1
10.0.100.1
Status
Status codes:
codes: ss suppressed,
suppressed, dd damped,
damped, hh history,
history, ** valid,
valid, >>
best, i - internal
best, i - internal
Origin
Origin codes:
codes: ii -- IGP,
IGP, ee -- EGP,
EGP, ?? -- incomplete
incomplete
Network
Network Next
Next Hop
Hop Metric
Metric LocPrf
LocPrf Weight
Weight Path
Path
*>10.0.70.0/24
*>10.0.70.0/24 10.0.20.2
10.0.20.2 307200
307200 32768
32768 ii
*>10.0.80.0/24
*>10.0.80.0/24 10.0.20.2
10.0.20.2 10000
10000 32768
32768 ??
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 88
88
Debugging MBGP
Two different commands are currently used to display the contents of the
Unicast RIB and the Multicast RIB. These are:
show ip bgp Shows the contents of the U-RIB
show ip mbgp Shows the contents of the M-RIB
The information displayed by the above commands is fundamentally the same.
The only difference is on is the contents of the Unicast RIB and the other is the
contents of the Multicast RIB.
Note:The syntax of the above commands will change in the near future to avoid
the confusing practice of referring to mbgp as meaning Multicast NLRI or
Multicast RIB instead of Multiprotocol BGP.
Network
Network Next
Next Hop
Hop Metric
Metric LocPrf
LocPrf Weight
Weight Path
Path
*>10.0.100.0/24
*>10.0.100.0/24 0.0.0.0
0.0.0.0 00 32768
32768 ii
Network
Network Next
Next Hop
Hop Metric
Metric LocPrf
LocPrf Weight
Weight Path
Path
*>10.0.70.0/24
*>10.0.70.0/24 10.0.20.2
10.0.20.2 307200
307200 32768
32768 ii
*>10.0.80.0/24
*>10.0.80.0/24 10.0.20.2
10.0.20.2 10000
10000 32768 ?
32768 ?
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 89
89
Debugging MBGP
Two different commands are currently used to display the contents of the
Unicast RIB and the Multicast RIB. These are:
show ip bgp Shows the contents of the U-RIB
show ip mbgp Shows the contents of the M-RIB
The information displayed by the above commands is fundamentally the same.
The only difference is on is the contents of the Unicast RIB and the other is the
contents of the Multicast RIB.
Note:The syntax of the above commands will change in the near future to avoid
the confusing practice of referring to mbgp as meaning Multicast NLRI or
Multicast RIB instead of Multiprotocol BGP.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 90
90
Debugging MBGP
Use the following command to display Multicast NLRI passed in MBGP update
messages.
debug ip mbgp updates
Use the following command to display Unicast NLRI passed in MBGP update
messages.
debug ip mbgp updates
Use the following command to display Multicast route flap dampening activity.
debug ip mbgp dampening [<acl>]
Use the following command to display Unicast route flap dampening activity.
debug ip bgp dampening [<acl>]
Note: The syntax of the above commands will change in the near future.
Module10. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/14/2001 3:35 PM 91
91
MBGP Summary
MBGP solves part of the inter-domain multicast problem by allowing ASs to
exchange Multicast RPF information in the for of MBGP Multicast NLRI.
Because this is accomplished using an extension to the BGP protocol to
make it support multiple protocols (i.e.Multiprotocol BGP), the same BGP
configuration knobs are available for both Unicast and Multicast information.
The separation of unicast and multicast prefixes into separate Unicast and
Multicast RIBs permits unicast and multicast traffic to follow different paths
if desired.
MBGP is only one piece of the overall Inter-domain Multicast solution and PIM
must still be used to:
Build the multicast distribution trees. (Typically via PIM-SM.)
Actually RPF check and forward multicast traffic.
PIM-SM is recommended as it permits the use of MSDP which solves most
of the remaining issues and is covered in another section.
ModuleN.ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 2
2
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 3
3
DVMRP MBONE
Virtual network overlaid (tunneled) on the
unicast Internet infrastructure
DVMRP MBONE uses RIP-like routing
Flood and Prune technology
Initially instantiated by MROUTED,
and later implemented by various router
vendors
Very successful in academic circles
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 4
4
DVMRP MBone
Historically, the very limited amount of multicast traffic that flowed across
the Internet used DVMRP Tunnels to interconnect multicast enabled
portions of the Internet together.
Unfortunately, DVMRP basically is an extension to the RIP unicast routing
protocol and has all of the problems associated with RIP as a routing
protocol.
DVMRP uses a Flood and Prune methodology where traffic is periodically
flooded to every part of the network and pruned back where it is
unwanted.
The first versions of DVMRP was the mrouted program that runs on
Unix platforms. Later implementations of DVMRP were developed by
commercial router vendors.
Initially, the DVMRP MBone was limited to academic sites and was
managed by a handful of dedicated academic types that kept it running
smoothly. The occasional outages were not considered to be a problem
since the MBone was largely seen as an academic experiment.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 5
5
DVMRP Problems
DVMRP has problems scaling to any significant size, particularly to the
size of the Internet. These problems include:
DVMRP is based on a Distance Vector routing protocol (RIP).
Periodic updates of the entire routing table are sent every 60 seconds. This
is fine for networks where the routing table is relatively small but is
unthinkable for really large networks such as the Internet were the number
of prefixes (routes) exceed 40,000.
Distance Vector based protocols suffer from some well know stability issues
including route Holddown, Count-to-Infinity and other problems.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 6
6
BR
BR
BR
Join Join r
BR
Domain G
BR
r BR BR r
Domain E Domain F
224.2.2.2
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 7
7
BGMP Example
In the above example, multicast group 224.2.2.2 has been assigned to
Domain B. Therefore, Domain B is the root domain for this multicast
group and this fact is communicated to all other domains.
Lets now assume that are receiver in Domain E joins multicast group
224.2.2.2. The last -hop router R directly connected to the receiver would
communicate this to the BGMP Border Routers (BR) by whatever method
is appropriate for the multicast routing protocol (PIM, MOSPF, DVMRP)
running in Domain E.
When the BGMP BR learns that there is a receiver in its domain for group
224.2.2.2, it sends a BGMP Join for group 224.2.2.2 toward the root
domain, Domain B. This Join travels domain by domain building a branch
of the Bidirectional BGMP Shared Tree from the root domain to Domain E.
If receivers in Domains F and G also join the multicast group, their last-
hop routers also trigger their BGMP BR to join the Bidirectional Shared
Tree by sending BGMP Joins toward the root domain.
The end result is a Bidirectional Shared Tree that connects all domains
that have active receivers for group 224.2.2.2.
Domain D
s BR
BR
BR
BR
r
BR
Domain G
BR
r BR BR r
Domain E Domain F
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 8
8
BGMP Example
Lets now assume that a source in Domain D connected to first -hop router
S goes active. This source traffic is routed by the Multicast IGP (PIM,
MOSPF, DVMRP) to the BGMP BRs that are on the Bidirectional Sha red
Tree for multicast group 224.2.2.2.
When the BGMP BRs receive this traffic, they forward it up/down the
Bidirectional Shared Tree.
The multicast traffic flows up and down the Bidirectional Shared Tree to
the BGMP BRs on all domains that are part of the Shared Tree.
The BGMP BRs that receive the multicast traffic, forward it via the
Multicast-IGP to the last-hop routers that have directly connected
receivers.
Notice that in some cases, a domain is acting as a transient domain. This
is the case for the root domain, Domain B. In this case, the multicast
traffic must be forwarded by the Multicast IGP in Domain B from one
BGMP BR to the other so that traffic will continue to flow down the
Bidirectional Shared Tree to Domain G.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 9
9
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 10
10
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 12
12
eMBGP
iMBGP
RP RP iMBGP
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 13
13
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 14
14
Solution: MSDP
Multicast Source Discovery Protocol
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 15
15
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 16
16
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 17
17
MSDP Overview
By abandoning the notion of inter-domain Shared-Trees and using only
inter-domain Source-Trees, the complexity of interconnecting PIM-SM
domains is reduced considerably.
The remaining problem becomes one of communicating the existence of
active sources between the RPs in the PIM-SM domains.
The RP can join the inter-domain source-tree for sources that are sending
to groups for which the RP has receivers. This is possible because the RP
is the root of the Shared-Tree which has branches to all points in the
domain where there are active receivers.
Note: If the RP either has no Shared-Tree for a particular group or a
Shared-Tree whose outgoing interface list is Null, it does not send a Join to
the source in another domain.
Once a last-hop router learns of a new source outside the PIM-SM domain
(via the arrival of a multicast packet from the source down the Shared-
Tree), it too can send a Join toward the source and join the source tree.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 18
18
MSDP Overview
The entire concept of MSDP depends on the RPs in the inter-connected
domains being the be-all, know-all oracle that is aware of all sources and
receivers in its local domain. As a result, MSDP can only work with PIM-
SM.
RPs know about all sources in a domain.
Whenever a source goes active in a PIM-SM domain, the first-hop router
immediately informs the RP of this via the use of PIM Register messages.
(S,G) state for the source is kept alive in the RP by normal PIM -SM
mechanisms as long the source is actively sending. As a result, the RP can
inform other RPs in other PIM-SM domains of the existence of active
sources in its local domain. This is accomplished via MSDP Source Active
(SA) messages.
RPs know about receivers in a domain.
Receivers cause last-hop routers to send (*, G) Joins to the RP to build
branches of a Shared-Tree for a group.
If an RP has (*, G) state for a group and the outgoing interface list of the (*,
G) entry is not Null, it knows it has active receivers for the group. Therefore,
when it receives an SA message announcing an active source for group G
in another domain, it can send (S, G) Joins toward the source in the other
domain.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 19
19
MSDP Overview
MSDP Peers (typically RPs) are connected via TCP sessions.
Note: The MSDP specification describes a UDP encapsulation option but
this is not currently available in the IOS implementation.
Source Active (SA) Messages
RPs periodically originate SA messages for sources that are active in their
local domain. These SA messages are sent to all active MSDP peers.
When a MSDP speaker receives an SA messages from one of its peers, it is
RPF forwarded to all of its other peers. An RPF check is performed on the
arriving SA message (using the originating RP address in the SA message)
to insure that it was received via the correct AS-PATH. Only if this RPF
check succeeds is the SA message flooded downstream to its peers. This
prevents SA messages from looping through the Internet.
Stub domains (i.e. domains with only a single MSDP connection) do not
have to perform this RPF check since there is only a single entrance/exit.
MSDP speakers may cache SA messages. Normally, these messages are
not stored to minimize memory usage. However, by storing SA messages,
join latency can be reduced as RPs do not have to wait for the arrival of
periodic SA messages when the first receiver joins the group. Instead, the
RP can scan its SA cache to immediately determine what sources are active
and send (S, G) Joins.
Non-caching MSDP speakers can query caching MSDP speakers in the
same domain for information on active sources for a group.
r
Domain C
RP
Domain B
RP
RP
Domain D
RP
Domain A
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 20
20
MSDP Example
In the example above, PIM-SM domains A through E each have an RP
which is an MSDP speaker. The solid lines between these RPs represents
the MSDP peer sessions via TCP and not actual physical connectivity
between the domains.
Note: The physical connectivity between the domains is not shown in the
drawing above.
Assume that a receiver in Domain E joins multicast group 224.2.2.2 which
in turn, causes its DR to send (*, G) Join for this group to the RP.
This builds a branch of the Shared-Tree from the RP in Domain E to the
DR as shown.
When a source goes active in Domain A, the first-hop router (S) sends a
PIM Register message to the RP. This informs the RP in Domain A that a
source is active in the local domain. The RP responds by originating an
(S, G) SA message for this source and send them to its MSDP peers in
domains B and C. (The RP will continue to send these SA messages
periodically as long as the source remains active.)
When the RPs in domains B and C receive the SA messages, they are
RPF checked and forwarded downstream to their MSDP peers. These SA
messages continue to travel downstream and eventually reach the MSDP
peers (the RPs) in domains D and E.
Note: The SA message traveling from domain B to domain C, will fail the
RPF check at the domain C RP (MSDP speaker) and will be dropped.
However, the SA message arriving at domain C from domain A will RPF
correctly and will be processed and forwarded on to domains D and E.
MSDP Peers RP
Source Active SA SA r
Messages Domain C
RP
SA
Domain B SA SA
RP
SA RP
SA SA Message
Domain D
192.1.1.1, 224.2.2.2
RP
SA Message
192.1.1.1, 224.2.2.2 s
Domain A
Register
192.1.1.1, 224.2.2.2
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 21
21
MSDP Example
In the example above, PIM-SM domains A through E each have an RP
which is an MSDP speaker. The solid lines between these RPs represents
the MSDP peer sessions via TCP and not actual physical connectivity
between the domains.
Note: The physical connectivity between the domains is not shown in the
drawing above.
Assume that a receiver in Domain E joins multicast group 224.2.2.2 which
in turn, causes its DR to send (*, G) Join for this group to the RP.
This builds a branch of the Shared-Tree from the RP in Domain E to the
DR as shown.
When a source goes active in Domain A, the first-hop router (S) sends a
PIM Register message to the RP. This informs the RP in Domain A that a
source is active in the local domain. The RP responds by originating an
(S, G) SA message for this source and send them to its MSDP peers in
domains B and C. (The RP will continue to send these SA messages
periodically as long as the source remains active.)
When the RPs in domains B and C receive the SA messages, they are
RPF checked and forwarded downstream to their MSDP peers. These SA
messages continue to travel downstream and eventually reach the MSDP
peers (the RPs) in domains D and E.
Note: The SA message traveling from domain B to domain C, will fail the
RPF check at the domain C RP (MSDP speaker) and will be dropped.
However, the SA message arriving at domain C from domain A will RPF
correctly and will be processed and forwarded on to domains D and E.
MSDP Peers RP
r
Domain C
.2.2.2)
RP
Join
(S, 224
Domain B
RP
RP
Domain D
RP
s
Domain A
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 22
22
MSDP Example
Once the SA message arrives at the RP (MSDP speaker) in domain E, it
sees that it has an active branch of the Shared-Tree for group 224.2.2.2. It
responds to the SA message by sending an (S, G) Join toward the source.
IMPORTANT: The (S, G) Join will follow the normal inter-domain routing
path from the RP to the source. This inter-domain routing path is not
necessarily the same path as that used by the MSDP connections. In order
to emphasis this point, the (S, G) Join is shown following a different path
between domains.
MSDP Peers RP
Multicast Traffic r
Domain C
RP
Domain B
RP
RP
Domain D
RP
s
Domain A
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 23
23
MSDP Example
Once the (S, G) Join message reaches the first -hop router (S) in domain A,
(S, G) traffic begins to flow to the RP in domain E via the Source Tree
shown.
IMPORTANT: The (S, G) traffic will not flow over the TCP MSDP sessions.
It will instead follow the path of the Source Tree that was built in the
preceding step.
MSDP Peers RP
Multicast Traffic r
Domain C Join
2)
(S, 224.2.2.
RP
Domain B
RP
RP
Domain D
RP
s
Domain A
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 24
24
MSDP Example
Once the (S, G) traffic reaches the last-hop router (R) in domain E, the last-
hop router may optionally send an (S, G) Join toward the source in order
to bypass the RP in domain E. This is shown in the above example.
MSDP Peers RP
Multicast Traffic r
Domain C
RP
Domain B
RP
RP
Domain D
RP
s
Domain A
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 25
25
MSDP Example
At this point in the example, the (S, G) traffic is flowing to the last-hop
router (R) in domain E via the Source-Tree as shown in the above
example.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 26
26
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 27
27
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 28
28
MSDP Peers
Like BGP, MSDP establishes neighbor relationships with other MSDP
peers.
MSDP peers connect using TCP port 639. The lower IP address peer takes
the active role of opening the TCP connection. The higher IP address peer
waits in LISTEN state for the other to make the connection.
MSDP peers send Keepalives every 60. The arrival of data performs the
same function as the Keepalive and keeps the session from timing out.
If no Keepalive or data is received for 75 seconds, the TCP connection is
reset and reopened.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 29
29
MSDP Peers
MSDP speakers must run BGP.
This requirement is due to the fact that the SA message RPF check
mechanism uses AS-PATH information contained in the MBGP M-RIB or U-
RIB.
There are some special cases where the requirement to perform an RPF
check on the arriving SA message is suspended. This is the case when
there is only a single MSDP peer connection or if the MSDP mesh groups
are in use. In these cases, (M)BGP is not necessary.
RP RP
A C
Interface Loopback 0
ip address 220.220.8.1 255.255.255.255
ip msdp peer 220.220.16.1 connect-
connect-source Loopback0
ip msdp peer 220.220.32.1 connect
connect-
-source Loopback0
RP
BGP TCP/IP
Peer Connection B
MSDP TCP/IP LO0 220.220.32.1
Peer Connection
MSDP Peers
Peer connections are establish by the use of the following IOS command:
ip msdp peer <ip-address> [connect-source <interface>]
In the above example Router A has MSDP peer connections with both
Routers B and C using their Loopback address as the connection address.
RP RP
A C
Interface Loopback 0
ip address 220.220.26.1 255.255.255.255
ip msdp peer 220.220.8.1 connect-
connect-source Loopback0
ip msdp peer 220.220.32.1 connect-
connect-source Loopback0
RP
BGP TCP/IP
Peer Connection B
MSDP TCP/IP LO0 220.220.32.1
Peer Connection
MSDP Peers
in the above example Router C has MSDP peer connections with both
Routers A and B using their Loopback address as the connection address.
RP RP
A C
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp peer 220.220.8.1 connect-
connect-source Loopback0
ip msdp peer 220.220.16.1 connect-
connect-source Loopback0
RP
BGP TCP/IP
Peer Connection B
MSDP TCP/IP LO0 220.220.32.1
Peer Connection
MSDP Peers
in the above example Router B has MSDP peer connections with both
Routers A and C using their Loopback address as the connection address.
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp default-
default-peer 220.220.8.1
MSDP TCP/IP
RP
B Peer Connection
LO0 220.220.32.1
MSDP Peers
Stub networks may use default peering to a single MSDP peer. This
eliminates the need to run (M)BGP to have the information necessary to
perform the RPF check on arriving SA messages.
Note: Since there is only a single connection, there is no need to perform
the RPF check since this is the only path that SA messages can take.
The format of the IOS command that establishes a default peer connection
is:
ip msdp default-peer <ip-address>
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp default-
default-peer 220.220.8.1
ip msdp default
default-
-peer 192.168.2.2
MSDP TCP/IP
RP
B Peer Connection
LO0 220.220.32.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 34
34
MSDP Peers
Stub networks may configure additional secondary default peer
connections to provide some redundancy in case the primary default
peer goes down.
In the above example, the primary default peer connection is to Router A
(220.220.8.1). The secondary default peer connection is to Router C.
This connection will not be activated unless the connect to Router A is
lost.
X
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp default-
default-peer 220.220.8.1
ip msdp default
default-
-peer 192.168.2.2
MSDP TCP/IP
RP
B Peer Connection
LO0 220.220.32.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 35
35
MSDP Peers
Continuing with the previous example, the primary default peer
connection is to Router A (220.220.8.1) has gone down. The secondary
default peer connection is to Router C is now activated.
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp peer 220.220.8.1 connect-
connect-source Loopback0
MSDP TCP/IP
RP
B Peer Connection
LO0 220.220.32.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 36
36
MSDP Peers
Stub networks may configure a single MSDP peer using the normal ip
msdp peer IOS command. When only a single MSDP peer is configured in
this manner, it is treated in the same manner as a default peering. This
eliminates the need to run (M)BGP to have the information necessary to
perform the RPF check on arriving SA messages.
Note: Since there is only a single connection, there is no need to perform
the RPF check since this is the only path that SA messages can take.
Interface Loopback 0
ip address 220.220.32.1 255.255.255.255
ip msdp peer 220.220.8.1 connect-
connect-source Loopback0
ip msdp peer 220.220.16.1 connect-
connect-source Loopback0
BGP TCP/IP
Peer Connection
MSDP TCP/IP
RP
B Peer Connection
LO0 220.220.32.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 37
37
MSDP Peers
If more than one MSDP peer is configured using the ip msdp peer
command, (M)BGP must also be configured.
In the example above, Router B has active MSDP peering sessions with
both Router A and Router C. In this case, (M)BGP must also be
configured so that Router B has the necessary AS-PATH information to
properly RPF Check arriving SA messages.
Note: The only exception to this rule is if all three routers are in an MSDP
Mesh Group. (Mesh Groups are discussed in a later section.)
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 38
38
MSDP Peers
Summary information on a routers MSDP peer connections can be
displayed using the following command:
show ip msdp summary
An MSDP connection can be reset by using the following command:
clear ip msdp peer
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 39
39
MSDP Peers
Detailed information on a routers MSDP peer connections can be
displayed using the following command:
show ip msdp peer [<peer-address>]
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 40
40
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 42
42
Problem
Need to know MSDP topology of Internet
But, MSDP does not distribute topology data!
Solution
Use (m)BGP data to infer MSDP topology.
Impact:
The MSDP topology must follow BGP topology.
An MSDP peer must generally also be an m(BGP) peer.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 43
43
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 44
44
Receiving SA Messages
RPF Check rules depend on the BGP peering between the MSDP peers.
Rule 1: Applied when the sending MSDP peer is also an i(m)BGP peer.
Rule 2: Applied when the sending MSDP peer is also an e(m)BGP peer.
Rule 3: Applied when the sending MSDP peer is not an (m)BGP peer.
RPF Checks are not done in the following cases:
If the sending MSDP peer is the only MSDP Peer. This would be the case if
a single msdp-peer command is configured or if only the default-peer
command is used.
If the sending MSDP peer is a Mesh-Group peer.
If the sending MSDP peer address is the RP address contained in the SA
message.
Implication
The MSDP peer address must be configured using the
same IP address as the (m)BGP peer!
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 45
45
Test Condition:
MSDP Peer address = BGP Neighbor address?
Implications:
The MSDP topology must mirror the (m)BGP
topology
Specifically, the MSDP peer address must be the
same as the i(m)BGP peer address!
If this condition is not met, RPF Check Rule 1 will
fail!!!
Pay attention to addresses used when
configuring MSDP and i(m)BGP peers.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 47
47
G F
172.16.6.1 172.16.5.1
Source
Rule 1 Example 1
In this example, router A receives an SA message originated by router G
from router E which is an i(m)BGP peer.
Applying Rule 1, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
This best path was received from i(m)BGP peer, 172.16.3.1
The sending MSDP peer address is also 172.16.3.1
Therefore the RPF check Rule 1 succeeds.
G F
172.16.6.1 172.16.5.1
Source
Rule 1 Example 2
In this example, router A receives the same SA message (originated by
router G) from router D which is an i(m)BGP peer.
Applying Rule 1, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
This best path was received from i(m)BGP peer, 172.16.3.1
The sending MSDP peer address is 172.16.4.1
Therefore RPF check Rule 1 fails.
X
MSDP Peer address != i(m)BGP Peer address
RP
172.16.1.1
RR
MSDP Peer address != i(m)BGP Peer address
X
SA RPF Check Fails
A
RP show
show ipip mbgp
mbgp 172.16.6.1
172.16.6.1
AS100 BGP
BGP routing
routing table
table entry
entry for
for 172.16.6.0/24,
172.16.6.0/24, version
version 8745118
8745118
Paths:
Paths: (1 available, best
(1 available,
BGP Peer best #1)
#1)
77 5, (received & used)
5, (received & used)
MSDP Peer 172.16.5.1
172.16.5.1 (metric
(metric 68096)
68096) from
from 172.16.1.1
172.16.1.1(172.16.1.1)
(172.16.1.1)
SA Message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 51
51
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 52
52
Test Condition:
First AS in path to the RP = AS of e(m)BGP peer?
Implication:
The MSDP topology must mirror the (m)BGP
topology
Should MSDP peer with the e(m)BGP peer.
Normal case is to configure MSDP peering
wherever e(m)BGP peering is configured.
Exception: When Rule 3 is used.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 53
53
G F
172.16.6.1 172.16.5.1
Source
First-AS in best-path to RP = 3
AS of MSDP Peer = 3
AS1 AS3
172.16.4.1 172.16.3.1
D E First-AS in best-path to RP = AS of e(m)BGP Peer
RP RP
SA RPF Check Succeeds
Router
Router A's
A's BGP
BGP Table
Table
Network Next
Next Hop Path
Network Hop Path
*>
*> 172.16.3.0/24 172.16.3.1 33 ii
172.16.3.0/24 172.16.3.1
172.16.3.0/24 172.16.4.1 11 33 ii
A 172.16.3.0/24 172.16.4.1
*>
*> 172.16.4.0/24 172.16.4.1 11 ii
RP 172.16.4.0/24 172.16.4.1
172.16.4.0/24 172.16.3.1 33 11 ii
172.16.4.0/24 172.16.3.1
AS100 *>
*> 172.16.5.0/24
172.16.5.0/24 172.16.3.1
172.16.3.1 33 77 ii
172.16.5.0/24 172.16.4.1 11 33 77 ii
BGP Peer 172.16.5.0/24 172.16.4.1
*>
*> 172.16.6.0/24 172.16.3.1 33 77 55 ii
172.16.6.0/24 172.16.3.1
MSDP Peer 172.16.6.0/24 172.16.4.1 11 33 77 55 ii
172.16.6.0/24 172.16.4.1
SA Message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 54
54
Rule 2 Example 1
In this example, router A receives an SA message originated by router G
via router E which is an e(m)BGP peer.
Applying Rule 2, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
The first-hop AS in the best path to the originating RP is AS3.
The origin AS of the sending MSDP peer (172.16.3.1) is also AS3. (This is
determined by locating the best-path to the MSDP peer and then finding the
last AS in the AS-Path list.)
Therefore the RPF check Rule 2 succeeds.
G F
172.16.6.1 172.16.5.1
Source
First-AS in best-path to RP = 3
AS of e(m)BGP Peer = 1
AS1 AS3
172.16.4.1 172.16.3.1
D E First-- AS in best-
First best - path to RP != AS of e(m)BGP Peer
RP RP
SA RPF Check Fails!
Router
Router A's
A's BGP
BGP Table
Table
Network Next
Next Hop Path
X Network
*>
*> 172.16.3.0/24
172.16.3.0/24
172.16.3.0/24
Hop
172.16.3.1
172.16.3.1
172.16.4.1
Path
33 ii
11 33 ii
A 172.16.3.0/24 172.16.4.1
*>
*> 172.16.4.0/24 172.16.4.1 11 ii
RP 172.16.4.0/24 172.16.4.1
172.16.4.0/24 172.16.3.1 33 11 ii
172.16.4.0/24 172.16.3.1
AS100 *>
*> 172.16.5.0/24
172.16.5.0/24 172.16.3.1
172.16.3.1 33 77 ii
172.16.5.0/24 172.16.4.1 11 33 77 ii
BGP Peer 172.16.5.0/24 172.16.4.1
*>
*> 172.16.6.0/24 172.16.3.1 33 77 55 ii
172.16.6.0/24 172.16.3.1
MSDP Peer 172.16.6.0/24 172.16.4.1 11 33 77 55 ii
172.16.6.0/24 172.16.4.1
SA Message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 55
55
Rule 2 Example 2
In this example, router A receives the same SA message (originated by
router G) via router D which is also an e(m)BGP peer.
Applying Rule 2, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
The first-hop AS in the best path to the originating RP is AS3.
The origin AS of the sending MSDP peer (172.16.4.1) is not AS3, it is AS1.
(This is determined by locating the best-path to the MSDP peer and then
finding the last AS in the AS-Path list.)
Therefore the RPF check Rule 2 fails.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 56
56
G F
172.16.6.1 172.16.5.1
Source
First-AS in best-path to RP = 3
AS of MSDP Peer = 3
AS1 AS3
172.16.4.1 172.16.3.1
D E First-AS in best-path to RP = AS of MSDP Peer
RP RP
SA RPF Check Succeeds
Router
Router A's
A's BGP
BGP Table
Table
Network Next
Next Hop Path
Network Hop Path
*>
*> 172.16.3.0/24 172.16.3.1 33 ii
172.16.3.0/24 172.16.3.1
B 172.16.3.0/24 172.16.4.1 11 33 ii
172.16.3.0/24 172.16.4.1
*>
*> 172.16.4.0/24 172.16.4.1 11 ii
AS100 172.16.4.0/24
172.16.4.0/24
172.16.4.1
172.16.3.1 33 11 ii
172.16.4.0/24 172.16.3.1
*>
*> 172.16.5.0/24 172.16.3.1 33 77 ii
172.16.5.0/24 172.16.3.1
RP 172.16.5.0/24 172.16.4.1 11 33 77 ii
BGP Peer A 172.16.5.0/24 172.16.4.1
*>
*> 172.16.6.0/24 172.16.3.1 33 77 55 ii
172.16.6.0/24 172.16.3.1
MSDP Peer 172.16.6.0/24 172.16.4.1 11 33 77 55 ii
172.16.6.0/24 172.16.4.1
SA Message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 57
57
Rule 3 Example 1
In this example, router A receives an SA message originated by router G
via router E which is neither an i(m)BGP peer nor an e(m)BGP peer.
Applying Rule 3, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
The first-hop AS in the best path to the originating RP is AS3.
The origin AS of the sending MSDP peer (172.16.3.1) is also AS3. (This is
determined by locating the best-path to the MSDP peer and then finding the
last AS in the AS-Path list.)
Therefore the RPF check Rule 3 succeeds.
G F
172.16.6.1 172.16.5.1
Source
First-AS in best-path to RP = 3
AS of MSDP Peer = 1
AS1 AS3
172.16.4.1 172.16.3.1
D E First-AS in best-path to RP != AS of MSDP Peer
RP RP
SA RPF Check Fails
Router
Router A's
A's BGP
BGP Table
Table
Network Next
Next Hop Path
Network Hop Path
*>
*> 172.16.3.0/24 172.16.3.1 33 ii
172.16.3.0/24 172.16.3.1
172.16.3.0/24 172.16.4.1 11 33 ii
X
B 172.16.3.0/24 172.16.4.1
*>
*> 172.16.4.0/24 172.16.4.1 11 ii
172.16.4.0/24 172.16.4.1
AS100 172.16.4.0/24
172.16.4.0/24 172.16.3.1
172.16.3.1 33 11 ii
*>
*> 172.16.5.0/24 172.16.3.1 33 77 ii
172.16.5.0/24 172.16.3.1
A RP 172.16.5.0/24 172.16.4.1 11 33 77 ii
BGP Peer 172.16.5.0/24 172.16.4.1
*>
*> 172.16.6.0/24 172.16.3.1 33 77 55 ii
172.16.6.0/24 172.16.3.1
MSDP Peer 172.16.6.0/24 172.16.4.1 11 33 77 55 ii
172.16.6.0/24 172.16.4.1
SA Message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 58
58
Rule 3 Example 2
In this example, router A receives the same SA message (originated by
router G) via router D which is neither an i(m)BGP peer nor an e(m)BGP
peer.
Applying Rule 3, the following occurs:
The best path in the BGP M-RIB for 172.16.6.1 (the originating RP) is
located.
The first-hop AS in the best path to the originating RP is AS3.
The origin AS of the sending MSDP peer (172.16.4.1) is AS1. (This is
determined by locating the best-path to the MSDP peer and then finding the
last AS in the AS-Path list.)
Therefore the RPF check Rule 3 fails.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 59
59
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 60
60
Processing SA Messages
The following steps are taken by a router whenever it processes an SA
message:
Using group address G of the (S, G) pair in the SA message, locate the
associated (*, G) entry in the mroute table.
If the (*, G) entry is found AND its outgoing interface list isnot Null, then
there are active receivers in the PIM-SM domain for the source advertised
in the SA message.
Create an (S, G) entry for the advertised source.
If the (S, G) entry did not already exist, immediately trigger an (S, G) Join
toward the source in order to join the source tree.
Flood the SA message to all other MSDP peers with the exception of:
The MSDP peer from which the SA message was received
Any MSDP peers that are in the same MSDP Mesh Group as this router.
(More on MSDP Mesh Groups later.)
Note: SA messages are not stored locally by the router unless SA-Caching
has been enabled on the router. (In most cases, Network Administrators
enable SA-Caching in order to improve network debugging capabilities.)
SA Filter Command:
ip msdp sa-filter {in|out} <peer-address> [list <acl>]
[route-map <map>]
SA Filtering
SA Filtering can be configured by the use of the following IOS command:
ip msdp sa-filter {in|out} <peer-address> [list <acl>] [route-map <map>]
The above command may be used to filter incoming or outgoing SA
Messages based on the (S, G) pairs specified in the list <acl> clause.
The above command may also be used to filter incoming or outgoing SA
Messages based AS-PATH using the route map specified by the route-
map <map> clause.
Caution: Arbitrary filtering of SA Messages can result in downstream
MSDP Peers from being starved of SA Messages for legitimate active
sources. Care should be used when using these sorts of filters so that
this does not occur. (Normally, these filters are only used to reject Bogons
such as sources in network 10.0.0.0, etc.)
Local Sources
A source is local if:
The router received a Register for (S, G), or
The source is directly connected to RP
SAs are only originated for local sources
Denoted by the A flag on an (S,G) entry
Other conditions may suppress SA messages
from being originated for local sources.
More on that later.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 63
63
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 64
64
Originating SA Messages
SA messages are triggered by an RP (assuming MSDP is configured)
when any new source goes active within the local PIM-SM domain.
When a source in the local PIM-SM domain initially goes active, it causes
the creation of (S, G) state in the RP. New sources are detected by the RP
by:
The receipt of a Register message or
The arrival of the first (S, G) packet from a directly connected source.
The initial multicast packet sent by the source (either encapsulated in the
Register message or received from a directly connected source) is
encapsulated in the initial SA message in an attempt to solve the problem
of bursty sources.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 65
65
Originating SA Messages
A TTL-Threshold problem can be introduced by the encapsulation of a
sources initial multicast packet in an SA Message. Because the multicast
packet is encapsulated inside of the unicast SA Message (whose TTL =
255), its TTL is not decremented as the SA message travels to the MSDP
peer. Furthermore, the total number of hops that the SA message
traverses can be drastically different than a normal multicast packet. This
is because multicast and unicast traffic may follow completely different
paths to the MSDP peer and hence the remote PIM-SM domain. This can
result in TTL-Thresholds being violated by this encapsulated packet.
The solution to this problem is to configure a TTL Threshold that is
associated with any multicast packet that is encapsulated in an SA
message sent to a particular MSDP peer. This can be accomplished by
configuring the following IOS command:
ip msdp ttl-threshold <peer-address> <ttl>
The above command prevents any multicast packet whose TTL is below
<ttl> from being encapsulated in an SA message sent to the MSDP peer
whose IP address is <peer-address> .
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 66
66
Originating SA Messages
By default, an RP configured to run MSDP will originate SA messa ges for
any and all local sources for which it is the RP. In some cases this may
not be desirable. (Example: If a sources inside the PIM-SM domain are
using private addresses such as network 10.0.0.0/8, it is generally not a
good idea to advertise these to other MSDP peers in the Internet.)
Control over which local sources should be advertised in SA Message can
be accomplished using the following IOS command on the RP:
ip msdp redistribute [list <acl>]
[asn <aspath-acl>]
[route-map <map>]
This command permits filtering of the SA messages that are originated
by the RP based on:
(S, G) pair using the list <acl> clause.
AS-PATH using the asn <aspath-acl> clause.
Other criteria using the route-map <map> clause.
Configuring this command without any of the acl or router-map clauses
causes all SA origination by this RP to be stopped. (Note: The router will
still forward SA messages from other MSDP peers in the normal fashion.
It will just not originate any of its own.
Authors Note: The choice of syntax for this command is a bit confusing
and could have been better chosen. The term redistribute typically implies
some other operation in IOS such as route redistribution. I prefer to
mentally translate the syntax of this command into ip msdp sa-originate-
filter because it is more descriptive of what the command actually does.
Once a minute
Router scans mroute table
If group = sparse AND router = RP for group
For each (S,G) entry for the group:
If the msdp redistribute filters permits
AND if the source is a local source
Then originate an SA message for (S,G)
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 67
67
Originating SA Messages
The RP continues to periodically (every 60 seconds) originate SA
messages for all active sources in the local PIM-SM domain for which it is
functioning as the RP. The details of this mechanism that is performed
every minute is as follows:
For all Sparse mode (*, G) entries in the mroute table for which the router
is functioning as the RP, originate an SA message for each subordinate
(S, G) entry that meets the following conditions:
The entry must be permitted by any msdp redistribute filters AND
The source is a local source. (Denoted by the A flag.)
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 68
68
MSDP Statistics
Information on the number of sources and groups being advertised on an
AS basis can be obtain by the use of the following IOS command:
show ip msdp count
The example show ip msdp count shown above indicates that:
There are a total of 1359 sources being advertised via MSDP
AS 24 is advertising 4 sources and 4 groups
AS 25 is advertising 3 sources and 3 groups
AS 52 is advertising 60 sources and 16 groups
etc, etc.
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 70
70
Optimises SA flooding
Useful when 2 or more peers are in a group
Reduces amount of SA traffic in the net
SAs are not flooded to other mesh-group
peers
No RPF checks on arriving SA messages
When received from a mesh-group peer
SAs always accepted from mesh-group peers
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 71
71
MSDP Mesh-Groups
An MSDP Mesh-Groups can be configured on a group of MSDP peers that
are fully meshed. (In other words, each of the MSDP peers in the group
has an MSDP connection to every other MSDP peer in the group.
When an MSDP Mesh-Group is configured between a group of MSDP
peers, SA flooding is reduced. This is because when an MSDP peer in the
group receives an SA message from another MDP peer in the group, it can
assume that this SA message was sent to all the other MSDP peers in the
group. As a result, it is not necessary nor desirable for the receiving
MSDP peer to flood the SA message to the other MSDP peers in the group.
MSDP Mesh -Groups may also be used to eliminate the need to run
(M)BGP to do RPF checks on arriving SA messages. This is because SA
messages are never flooded to other MSDP peers in the mesh-group. As a
result, it is not necessary to perform the RPF check on arriving SA
messages.
Configured with:
ip msdp mesh-group <name> <peer-address>
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 72
72
MSDP Mesh-Groups
A MSDP Mesh -Group may be configured by using the following IOS
configuration command:
ip msdp mesh-group <name> <peer-address>
This command configures the router as a member of the mesh-group
<name> for which MSDP peer <peer-address> is also a member.
All MSDP peers in the mesh-group must be fully-meshed with all other
MSDP peers in the group. This means that each router must be configured
with ip msdp peer and ip msdp mesh -group commands for each
member of the mesh-group.
Routers may be members of multiple Mesh-Groups.
ip msdp peer R2
ip msdp peer R3 SA not forwarded to other
ip msdp mesh-group My-Group R2 members of the mesh -group
ip msdp mesh-group My-Group R3 R1
SA
X
RP RP
X
SA
R4 R2 SA R5
SA
R3
ip msdp peer R1
ip msdp peer R3 ip msdp peer R1
ip msdp peer R4 ip msdp peer R2
ip msdp mesh-group My-Group R1 ip msdp peer R5
ip msdp mesh-group My-Group R3 ip msdp mesh-group My-Group R1
ip msdp mesh-group My-Group R2
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 73
73
SA Loop!!!
RP RP RP RP
AS1 AS3
Mesh-group as1
Mesh-group as3
Mesh-group as1-as3
MSDP Peering
i(m)BGP Peering
e(m)BGP Peering
DONT DO THIS!!!!
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 74
74
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 75
75
Note: Arriving SA messages must pass any incoming SA filters that have
been configured.
Note: The SA messages must pass any outgoing SA filters that have been
configured before it is sent.
SA Caching Cons
Consumes more memory
Minor memory impact to date
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 77
77
SA Caching Pros
Reduces Join latency
When this SA caching is configured, the router will begin caching all (S,G)
pairs received in SA messages. This reduces join latency as the RP
maintains a list of all active sources. Therefore, when the first receiver joins
the group, the RP doesnt have to wait 60 seconds for the next SA message
before sending out the (S,G) Join.
Valuable debugging tool
The contents of the SA cache is a valuable source of MSDP debugging
information. The show ip msdp sa-cache command will list its contents
and display all active sources in the Internet along with information on what
AS they reside and what RP advertised it.
Helps prevent SA Storms
Since SAs are advertised periodically from cache (instead of as soon as
they are received from an upstream neighbor), the propagation of SA
messages through out the Internet are better paced. This helps to avoid
overrunning TCP input queues on the MSDP peers which results in session
resets and instability of MSDP.
SA Caching Cons
Memory consumption
The memory impact of turning on SA Caching in most RPs is, in general,
very small.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 78
78
Note: Arriving SA messages must pass any incoming SA filters that have
been configured.
Enabling SA Caching
ip msdp cache-sa-state [list <acl>]
Caching is on by default
Beginning with IOS versions 12.1(7), 12.0(14)S1
Cannot be turned off.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 79
79
Enabling SA Caching
SA caching can be enabled by the use of the following IOS command :
ip msdp cache-sa-state [list <acl>]
When this command is configured, the router will begin caching all (S,G)
pairs received in SA messages. This reduces join latency as the RP
maintains a list of all active sources. (The memory impact of turning on
SA Caching in most RPs is, in general, very small. The other benefit is
that additional information becomes available for network debugging if SA
Caching is enabled.)
The optional list <acl> clause may be used to control which (S,G) pairs
are cached. If this optional clause is not specified, all (S,G) pairs are
cached.
(S,G) pairs in the SA cache have a 6 minute timeout. If a new SA message
is not received with this (S,G) pair in that period, the entry is removed from
the cache.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 80
80
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 81
81
MSDP SA Caching
Routers that do not have SA Caching enabled can benefit from other
routers that are SA Caching enabled by sending SA Request messages
whenever receivers first join a group. In order to enable the se nding of SA
Requests, the following IOS command must be configured:
ip msdp sa-request <server-address>
This command will cause the router to send an SA-Request message to
the SA Caching router whose IP address is <server-address> under the
following conditions:
When the outgoing interface list of a (*,G) entry goes from Null to non-Null
AND
The router is the RP for group G.
SA-Request filtering
ip msdp filter-sa-request <ip-address> [list <acl>]
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 82
82
SA Request Filtering
In some situations, a router that has SA Caching enabled may not wish to
honor all received SA Request messages. If this is desired, an SA
Request filter may be configured using the following IOS command :
ip msdp filter-sa-request <ip-address> [list <acl>]
This command will cause the router to filter all SA-Requests received from
the router whose IP address is <ip-address> based on the optional list
<acl> clause. If the optional list <acl> clause is not specified, the
default behavior is to not respond to SA Requests from this router.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 83
83
MSDP SA Caching
The contents of the SA Cache can be very helpful to debugging MSDP
problems in the network. (This is why most network administrators
enable SA Caching on all MSDP routers.) The following IOS command can
be used to display the contents of the SA Cache:
show ip msdp sa-cache [<group-or-source>] [<asn>]
The above command lists the contents of the SA Cache. The optional
<group-or-source> and <asn> qualifiers may be used to limited the
displayed output to only those desired entries.
In the above example of this command we see that there are 1997 entries
in the SA Cache. The information on the first entry is as follows:
(192.92.8.77, 224.2.232.0) = Active source/group information
RP 194.177.210.41 = IP address of the originating RP.
MBGP/AS 5408 = The RP resides in AS 5408
00:01:51/00:04:09 = The source has been active for 1 min,
51 sec and will expire in 4 min, 9 sec.
The contents of the SA Cache can be cleared by the use of the following
IOS command:
clear ip msdp sa-cache [<group-address> | <group-name>]
The optional <group-address> and <group-name> qualifiers may be
specified to limit which entries are to be cleared from the cache.
RP RP
RR
RP RP
Customer
Customer
RP
MSDP Peering
i(m)BGP Peering Customer
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 84
84
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 85
85
Inter-domain Multicast
Past & Future
MSDP Overview
MSDP Peers
MSDP Messages
MSDP Mesh Groups
MSDP SA Caching
MSDP Applications
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 86
86
draft-ietf-mboned-anycast-rp-nn.txt
Within a PIM-SM domain, deploy more than
one RP for the same group range.
Each RP configured with the same IP address.
DRs use closest RP
Sources and receivers are registered/joined to
the closest RP.
RPs use MSDP to inform each other about
active sources in their part of the domain.
Other RPs join SPT to these sources as
needed.
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 87
87
Anycast RP
MSDP may be used to implement the concept of Anycast RPs within a
PIM-SM domain to provide RP redundancy, rapid RP fail-over and RP load-
balancing. This concept was first documented in the following IETF draft:
draft-ietf-mboned-anycast-rp-nn.txt
The Anycast RP mechanism works as follows:
Two or more routers are configured as active RP for the same group range
at the same time. (This is normally is a configuration error that would
partition the PIM -SM domain. However, MSDP is used to prevent this from
happening.)
Each RP is assigned the same RP Address. (This is usually accomplished
using a Loopback interface and private address space.) Each router
advertises its RP address as a host route in the unicast routing protocol.
Sources and receivers (more specifically, their DRs) will use the closest RP
based on their unicast routing table.
The Anycast RPs are all connected via MSDP. This allows each RP to
learn which sources have been registered with the other Anycast RPs in the
domain.
The normal PIM -SM RP behavior will result in the RPs joining the source
tree of active sources in the other parts of the network as necessary.
Benefits
RP backup without using Auto-RP or BSR.
RP fail-over at speed of unicast routing
protocol.
Requirements
Use only one IP address for all your RPs.
RPs advertise this address as a host route.
MSDP is used between the RP routers.
Use ip msdp originator-id command.
Disambiguates which RP originated SA message
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 88
88
Anycast RP Benefits
Anycast RPs provide for backup RPs without having to use Auto-RP or
BSR.
RP fail-over occurs roughly at the same speed as the unicast routing
protocol converges.
Anycast RP Requirements
All Anycast RPs are configured to use the same IP address.
All Anycast RPs advertise this IP address as a host route. This causes
the DRs in the network to see only the closest RP.
Note: If there does happen to be a metric tie, the normal RPF mechanism
will select the only one path back to the RP. The path selected will be the
one that has the highest next hop address.
All Anycast RPs are tied together via MSDP peering sessions.
The ip msdp originator-id command is used to control the IP address that
is sent in any SA messages that are originated by an RP.
This is done to disambiguate which RP originated the SA message. If this
were not done, all RPs would originate SA messages using the same IP
address.
RP1 RP2
MSDP
A
A B
B
10.1.1.1 10.1.1.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 89
89
Anycast RP Overview
In the drawing above, two Anycast RPs are configured with the same IP
address, RP1 in San Francisco and RP2 in New York. Each are connected
via MSDP.
(Yes, you must use some other address in the ip msdp peer commands
than 10.0.0.1.)
Src Src
RP1 RP2
MSDP
A
A B
B
10.1.1.1
SA SA 10.1.1.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 90
90
Anycast RP Overview
Notice that initially, the DRs for the sources and receivers register to the
closest RP based on their unicast routing table entry for IP address
10.0.0.1. This causes in DRs in the eastern half of the U.S. to register/join
to the RP in New York while the DRs in the western half register/join to
the RP in San Francisco.
When a new source registers with the nearest RP, that RP will se nd an
MSDP SA message to its peer. This will cause the peer RP to join the SPT
to the new source so it can pull the sources traffic to itself and then send
it down the shared tree to its receivers.
Src Src
X RP1 RP2
A
A B
B
10.1.1.1 10.1.1.1
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 91
91
Anycast RP Overview
Continuing with our example, lets assume that the RP in San Fra ncisco
goes down. When the unicast routing protocol reconverges, all of the
DRs in the western half of the U.S. will now see the route to IP address
10.0.0.1 points toward the the New York RP. This results in new
registers/joins being sent by the DRs in the western half of the U.S. to the
RP in New York and the flow of traffic is reestablished.
E0
S0
10.1.1.1 via E0
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 92
92
Anycast RP Example
In this example, two Anycast RPs are configured with the same IP
address, 10.0.0.1, using Loopback 0.
Each are connected via MSDP using their Loopback 1 addresses, 10.0.0.2
and 10.0.0.3.
(Yes, you must use some other address in the ip msdp peer commands
than 10.0.0.1.)
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 93
93
Anycast RP Tips
Care must be taken to prevent the Loopback addresses being used for the
Anycast RPs from being accidentally used as the Router-ID for OSPF and
BGP.
If this occurs, there will be multiple OSPF/BGP routers in the network with
the same Router-ID. (Can you say, My network is broken? Sure, I knew
you could.)
Avoiding the Router-ID conflict:
Configure the Anycast RP Loopback address using the lowest IP address in
the box.
Configure a secondary address on the Loopback address and use this
address for Anycast RP configuration.
Use the router-id configuration commands to statically configure the OSPF
and/or BGP Router-ids.
int pos0/0
ip pim sparse-dense-mode
192.168.100.0/24
ip pim send-rp-announce Loopback0 scope 255
ip pim send-rp-discovery Loopback0 scope 255
Receiver
int pos0/0
ip pim sparse-dense-mode
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 94
94
Group(s) 224.0.0.0/4
192.168.100.0/24
RP 3.3.3.7 (loopback.transit.net), v2v1
Info source: 1.1.1.2 (tail.transit.net), via Auto-RP
Receiver Uptime: 21:57:41, expires: 00:02:08
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 95
95
Group(s) 224.0.0.0/4
RP 3.3.3.7 (loopback.transit.net), v2v1
Info source: 3.3.3.7 (loopback.transit.net), via Auto-RP
Uptime: 22:08:47, expires: 00:02:14
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 96
96
192.168.100.0/24
ip route 192.168.100.0 255.255.255.0 1.1.1.1
Receiver
router bgp 109
...
network 192.168.100.0 nlri unicast multicast
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 97
97
- no RP / no MSDP
192.168.100.0/24
- no downstream RP
Receiver - no downstream MSDP peering
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 98
98
int pos0/0
ip pim sparse-mode
ip pim bsr-border
ip multicast boundary 1
192.168.100.0/24
ip msdp sa-filter out 1.1.1.2 111
Receiver ip msdp sa-filter in 1.1.1.2 111
int pos0/0
192.168.100.0/24 ip pim sparse-mode
ip pim bsr-border
Receiver ip multicast boundary 1
192.168.100.0/24
ip route 192.168.100.0 255.255.255.0 1.1.1.1
Receiver
router bgp 109
...
network 192.168.100.0 nlri unicast multicast
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 101
101
192.168.100.0/24
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 102
102
int pos0/0
ip pim sparse-mode
ip pim bsr-border
ip multicast boundary 1
192.168.100.0/24
ip msdp sa-filter out 1.1.1.2 111
Receiver ip msdp sa-filter in 1.1.1.2 111
int pos0/0
192.168.100.0/24 ip pim sparse-mode
ip pim bsr-border
Receiver ip multicast boundary 1
Receiver
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 105
105
192.168.100.0/24
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 106
106
Transit AS110
int pos0/0 pos0/0 1.1.2.2
ip pim sparse-mode
192.168.100.0/24
ip pim bsr-border
ip multicast boundary 1
Receiver Unicast
int pos1/0
Transit
ip msdp sa-filter out 1.1.1.2 111
ip msdp sa-filter in 1.1.1.2 111
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 107
107
Transit AS110
pos0/0 1.1.2.2
int
192.168.100.0/24 pos0/0
ip pim sparse-mode
ip pim bsr-border
Receiver Unicast
ip multicast boundary 1
Transit
ip msdp sa-filter out 1.1.1.1 111
ip msdp sa-filter in 1.1.1.1 111
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 108
108
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Receiver Unicast
Transit
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 109
109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 110
110
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Receiver Unicast
router bgp 109
neighbor 1.1.1.1 remote-as 100 nlri multicast Transit
neighbor 1.1.1.1 update-source pos 0/0
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 111
111
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Receiver Unicast
Transit
router bgp 110
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source pos0/0
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 112
112
Receiver Unicast
ip msdp peer 1.1.1.1 connect-source pos0/0
Transit
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 113
113
int pos0/0
ip pim sparse-mode Transit AS110
ip pim bsr-border pos0/0 1.1.2.2
ip multicast boundary 1
192.168.100.0/24
int pos1/0
ip pim sparse-mode
Receiver ip pim bsr-border RP Unicast & Multicast
ip multicast boundary 1 Transit
ip msdp sa-filter out 1.1.1.2 111
ip msdp sa-filter in 1.1.1.2 111
ip msdp sa-filter out 1.1.2.2 111
ip msdp sa-filter in 1.1.2.2 111
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 114
114
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
int pos0/0
Receiver ip pim sparse-mode
ip pim bsr-border RP Unicast & Multicast
ip multicast boundary 1 Transit
ip msdp sa-filter out 1.1.1.1 111
ip msdp sa-filter in 1.1.1.1 111
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 115
115
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Receiver
RP Unicast & Multicast
router bgp 109 Transit
neighbor 1.1.1.1 remote-as 100 nlri unicast multicast
neighbor 1.1.1.1 update-source pos 0/0
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 118
118
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24
Receiver
RP Unicast & Multicast
Transit
Module11. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 2:33 PM 120
120
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 1
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 2
2
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 3
3
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 4
4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 5
5
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 6
6
A B C D
Out-of-band
PIM (S, G) Join source directory,
example: web server
Receiver 1
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 7
7
SSM Example
The prerequisite for SSM deployment is a mechanism that allows hosts not only
to report the group they want to join but also the source for the group. This
mechanism is built into emerging IGMP version3 standard. With IGMP v3 last-
hop routers learn from the report for the multicast source and the group. It then
simply creates (S,G) Join and forwards it directyl to the source.
The ways how hosts learn about existence of sources can be different
normally via some directory services (session announcements directly from
sources or some out -of-band mechanisms, e.g. web pages). Most of those
mechanisms distribute the information via multicast.
A B C D
Out-of-band
source directory,
example: web server
E F
Receiver 1
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 8
8
SSM Example
The result of building source-rooted tree (shortest-path tree) right from beginning
is that RP mechanisms for source-specific groups are completely eliminated.
The RPs for those groups are not needed any more and routers must not build
shared trees for groups in the range 232/8.
The benefits of building shortest-path trees directly (and not via PIM Sparse
mode switchover mechanism) are evident the latency of multicast traffic is
decreased and less multicast state is kept in multicast forwarding tables.
Another major benefit of SSM in in address management. Traditionally multicast
applications had to acquire a unique IP multicast group address because traffic
distribution was based only on the group address used. When two applications
with different sources and receivers used the same IP multicast group address,
the receivers received the traffic from both sources.
In SSM, traffic from each source is forwarded between routers in the network
independent of traffic from other sources. Thus different sources can reuse
multicast group addresses in the SSM range
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 9
9
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 10
10
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 11
11
IGMPv3:
Should eventually become industry standard.
Cisco IGMPv3 implementation in IOS 12.1(3)T and
12.0(15)S.
Questions:
When will host Operating Systems get IGMPv3 support?
When will applications be written to use IGMPv3
support?
Do we want to wait for all this to happen?
Answer: No!
We need the benefits of IP SSM today to:
Resolve certain multicast Security issues
Avoid address collisions
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 14
14
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 16
16
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 17
17
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 18
18
URD Overview
The idea of URD as an interim solution for transition to IGMP v3 is that the
content provider builds a web page that contains URD links. Those links contain
information on sources that are willing to provide the multicast content for certain
groups.
When a user clicks on such a link the browser of a host will try to open a TCP
connection to the web server on port 659. If the last hop router is enabled for
URD on the interface where the router receives the TCP packets from the host,
it will intercept all packets for TCP connections destined to port 659 independent
of the actual destination address of the TCP connection. From the information in
URD the router learns about sources and groups.
Because normal IGMPv1/v2 group membership reports are still sent by the
application, URD is compatible with IGMPv1/v2 snooping and CGMP in
switches.
Click
Click here for the Sports
Http:/www.broadcast.com/sports.htm
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 19
19
Currently showing
Euro 2000 Soccer
live from Brussels
England : Germany
3:1
Min 89:00
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 20
20
England : Germany
3:1
Min 89:00
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 21
21
England : Germany
3:1
Min 89:00
That is..
Unless some unwanted traffic
disturbs the reception, maybe
some DoS attack...
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 22
22
England : Germany
3:1
Min 89:00
England : Germany
3:1
Min 89:00
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 25
25
Http:/www.broadcast.com/sports.htm
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 26
26
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 27
27
...
<FRAME
SRC="http://sessions.broadcast.com/sports.sdp"
NAME=Frame to start receiver app"
>
...
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 28
28
i=Sports Channel Actual URL content
c=232.3.4.5 ...
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 29
29
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 30
30
i=Sports Channel
c=232.3.4.5 ...
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 31
31
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 32
32
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 33
33
Currently showing
Euro 2000 Soccer
live from Brussels
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 34
34
Min 89:00
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 35
35
Currently showing
Euro 2000 Soccer
live from Brussels The
England : Germany
3:1
Internet The web server
Min 89:00 www.broadcast.com
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 36
36
Currently showing
Euro 2000 Soccer
live from Brussels The
England : Germany
3:1
Internet The web server
Min 89:00 www.broadcast.com
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 37
37
Currently showing
Euro 2000 Soccer
live from Brussels The
England : Germany
3:1
Internet The web server
Min 89:00 www.broadcast.com
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 38
38
Currently showing
Euro 2000 Soccer
live from Brussels The
England : Germany
3:1
Internet The web server
Min 89:00 www.broadcast.com
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 40
40
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 41
41
Min 89:00
HTTP/1.0 www.broadcast.com
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 42
42
And once it sees the first IGMPv1/v2 report for the group (from the
application), the router will join to the source via PIM-SS and continue
as long as the IGMPv1/v2 group reports come in.
Note: The URL request from the browser and the first IGMPv1/2 report
from the application may arrive in any order within ~ 1 minute
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 43
43
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 44
44
England : Germany
3:1
Min 89:00
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 45
45
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 46
46
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 47
47
Source side:
No application changes required!
Receiver side IGMPv3 API:
draft-ietf-idmr-msf-api-00.txt
Socket Interface Extensions for Multicast Source Filter
Supports all memberships possible with IGMPv3:
Group membership with INCLUDE or EXCLUDE list of
sources.
Different subsets of the API defined (one for IP SSM)
Kernel implementation of this will also filter out any
unwanted received traffic still forwarded to host.
Layer2 of hosts is not IP SSM aware, input filtering on
group only.
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 48
48
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 49
49
IP SSM
IP SSM
Application
Application
(s) IGMP
v3lite Cisco IOS 12.1(3)T
IP SSM API Daemon
IP SSM API or later router with
HSIL ip igmp v3lite
HSIL
enabled
Host
Operating System
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 50
50
IP SSM
IP SSM
Application
Application
(s) IGMP
v3lite Cisco IOS 12.1(3)T
Join (S,G)
IP SSM API Daemon
IP SSM API or later router with
HSIL ip igmp v3lite
HSIL
enabled
Host
Operating System
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 51
51
IP SSM
IP SSM
Application
Application
(s) IGMP
v3lite Cisco IOS 12.1(3)T
Join (S,G)
IP SSM API Daemon
IP SSM API or later router with
HSIL ip igmp v3lite
HSIL
enabled
Join (G)Host
Operating System
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 52
52
IP SSM
IP SSM
Application
Application
(s) IGMP
v3lite Cisco IOS 12.1(3)T
Join (S,G)
IP SSM API Daemon
IP SSM API or later router with
HSIL ip igmp v3lite
HSIL
enabled
UDP Port:659
Membership
Join (G)Host report
INCLUDE
Operating System (S,G)
IGMPv1/v2
membership report for G
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 53
53
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 54
54
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 55
55
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 56
56
One-to-Many Applications
Video, TV, Radio, Concerts, Stock Ticker, etc.
Few-to-Few Applications
Small (<10 member) Video/Audio Conferences
Few-to-Many Applications
TIBCO RV Servers (Publishing)
Many-to-Many Applications
Stock Trading Floors, Gaming
Many-to-Few Applications
TIBCO RV Clients (Subscriptions)
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 57
57
One-to-Many Applications
Single (S,G) entry
Few-to-Few Applications
Few (<10 typical) (S,G) entries
Few-to-Many Applications
Few (<10 typical) (S,G) entries
Many-to-Many Applications
Unlimited (S,G) entries
Many-to-Few Applications
Unlimited (S,G) entries
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 58
58
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 59
59
Bidirectional Shared-Trees
Allows data to flow up the Shared Tree
Source traffic follows Shared Tree to get to the
RP and all other receivers on the Shared Tree
Cannot use current (*,G) RPF rules
Care must be taken to avoid multicast loops
Requires a Designated Forwarder (DF)
Responsible for forwarding traffic up Shared Tree
DFs will accept data on the interfaces in their OIL.
Then send it out all other interfaces. (Including the IIF.)
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 61
61
Idea:
Use the same tree for traffic from sources
towards RP and from RP to receivers
Benefits:
Less state in routers
Only (*, G) state is used
Source traffic follows the Shared Tree
Flows up the Shared Tree to reach the RP.
Flows down the Shared Tree to reach all other receivers.
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 62
62
Bidir PIM
PIM Sparse Mode in its native form is unidirectional the traffic from sources to
the RP initially flows encapsulated in Register messages wich presents a
significant burden due to encapsulation / decapsulation mechanisms.
Additionally, shortest path tree is built between the RP and the source (initiated
by the RP) which results in (*,G) and (S,G) entries at least on the way between
the RP and the source.
Several multicast applications use many-to-many model where each participant
is receiver and sender as well. In such an environment (*,G) and (S,G) entries
appear everywhere along the path from participants and the associated RP in a
PIM Sparse Mode domain resulting in increased memory and protocol
overhead. It is also possible that the path from the source to the RP and the
opposite path (from the RP to the source which is a receiver as well) are
incongruent.
Bi-directional PIM dispenses with both encapsulation and source state by
allowing packets to be natively forwarded from a source to the RP using shared
tree state only. This ensures that only (*,G) entries will appear in multicast
forwarding tables and that the path taken by packets flowing from the participant
(source and/or receiver) to the RP and vice versa will be the same.
RP Sender/
Receiver Receiver
Shared Tree
Receiver
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 63
63
RP Sender/
Receiver Receiver
Shared Tree
Source Traffic
Receiver
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 64
64
RP Sender/
Receiver Receiver
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 65
65
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 66
66
N1 N2
DF
Join to DF Join to DF
N3 N4
R1 R2
Shared Tree
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 67
67
N3 N4
R1 R2
Shared Tree
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 68
68
N3 N4
R1 R2
Shared Tree
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 69
69
R1 R2
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 70
70
Forwarding/Tree Building
The Designated Forwarder (DF) has all the responsibilities for forwarding
multicast traffic in bidirectional PIM. It has to forward multicast traffic received on
a link for which it is a DF via RPF-interface towards the RP (in addition to
forward the traffic via interfaces in OIL excluding the inteface on which the traffic
was received).
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 71
71
DF Election
The election of a Designated Forwarder on each link follows similar principles
known from the Assert process in PIM Dense Mode. The mechanism ensures
that all the routers on the link have consistent view of the same RP. To perform
the election of the DF for a particular RP, routers on a link need to exchange
their unicast routing metric information for reaching the RP.
Note: The election of a DF is per RP and not per individual group.
The election process happens once only - when information on a new RP
becomes available. There are however some conditions where an update to the
election is needed:
A change in unicast metric to reach the RP for any of the routers on the link
The interface on which the RP is reachable changes to an interface for
which the router was previously the DF
A new PIM neighbor on a link
The elected DF dies
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 73
73
DF Election Messages
The DF election mechanism is based on four control messages exchanged
between the routers on the link.
The Offer message is used to advertise router`s unicast metric to reach the
RP and is used for comparison with other routers participating in DF
election.
The Winner message allows the winning router to declare to every other
router on the link the identity of the winner and the metrics it is using. The
message is used by the DF to reassert its status as well.
The Backoff message is used by the DF on receipt of an offer that is better
than its own metric. The DF records the received information and responds
with a Backoff message. This instructs the offering router to hold off for a
short period of time while the unicast routing stabilizes.
The Pass message is used by the acting DF to pass its role to another
router offering better metric. The old DF stops its tasks as soon as the
transmission is made.
On RP discovery
send Offer with
metric to RP. RP
N1 N2
Offer 10
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 74
74
Initial Election
When a router finds out a new RP and the DF does not exist yet it sends an
Offer message. The message contains the router`s metric to reach the RP and
the router`s identity. The Offer message is periodically (Offer-Interval)
retransmitted.
If the router learns about a better metric from a neighbor it stops sending Offer
messages for a period of three times the Offer-Interval. If after this period no
winner is elected, the election is restarted by the router. The same happens if an
Offer with a worse metric is received.
A router takes the role of the DF after sending three Offers without receiving any
offer from any other neighbor.
On RP discovery
send Offer with
metric to RP. We are RP
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 75
75
Initial Election
When neighbors hear the Offer message they compare the offered metric with
their own one. If their metric is worse they back off (remain silent for three times
the Offer-Interval) and thus allow the offering router to win. A timer is still running
to restart offering in case election fails.
If the neighbor that heard the Offer has better metric it actively starts
participating in the election by sending its own Offer messages including its
metric to the RP and its identity.
On RP discovery
send Offer with
metric to RP. We are RP
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 76
76
Initial Election
If the offering router hears an Offer with a better metric it assumes it lost and
stops sending Offer messages for the period of three times the Offer-Interval. If
after that interval the situation is not yet resolved, the election process will
restart.
On RP discovery
send Offer with
metric to RP. RP
Initial Election
The router that sent the better Offer three times (and hasn`t heard of better Offer
or no Offer at all) assumes the DF role and transmits a Winner message which
declares to every router on the link the identity of the winner and the metric it is
using.
Routers hearing a Winner message stop participating in the election and record
the identity and metrics of the winner.
Winner message
informs the other
routers who is DF. RP
We Win! DF is N1
N1 N2
Winner 8
DF is N1 DF is N1
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 78
78
Initial Election
The router that sent the better Offer three times (and hasn`t heard of better Offer
or no Offer at all) assumes the DF role and transmits a Winner message which
declares to every router on the link the identity of the winner and the metric it is
using.
Routers hearing a Winner message stop participating in the election and record
the identity and metrics of the winner.
RP
Candidate
N1 N2
DF Offer 6
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 79
79
DF Preemption
Once the DF is elected the process does not restart if there are no changes in
metrics, PIM neigbors, DF reachability or interfaces towards the RP. If the
unicast metric to a RP changes for a non-DF router to a value that is better than
that previously advertised by the DF the router sends a new Offer. A new Offer
includes an improved metric and the candidate`s identity.
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 80
80
DF Preemption
Upon receipt of an Offer that is better than its current metric, the DF records the
identity and metrics of the offering router and responds with a Backoff message
(including the metric of the candidate that just sent the Offer).
The offering router will hold off for a period of time (defined in the Backoff
message) while the unicast routing stabilises. All routers on the link who have
pending offers with metrics equal or worse than those in the backoff message
(including the original offering router) will hold further offers for the defined
period.
If during the period someone else sends a new better Offer, the Backoff
message is repeated for the new Offer and the backoff period restarted.
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 81
81
DF Preemption
Just before the backoff period expires, the current DF declares the candidate
router with the best Offer as the new DF. This is done via a Pass message
which includes the IDs and metrics of both the old and new DFs.
The current DF stops acting as a DF soon after the Pass is transmitted. The new
DF assumes the role of the DF as soon as it receives the Pass message. All
other routers on the link record the identity and the metric of the newly elected
DF.
On receipt candidate
becomes DF. N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 82
82
DF Preemption
Just before the backoff period expires, the current DF declares the candidate
router with the best Offer as the new DF. This is done via a Pass message
which includes the IDs and metrics of both the old and new DFs.
The current DF stops acting as a DF soon after the Pass is transmitted. The new
DF assumes the role of the DF as soon as it receives the Pass message. All
other routers on the link record the identity and the metric of the newly elected
DF.
On receipt candidate
becomes DF. N3 N4
DF is N2 DF is N2
Other routers hear Pass,
learn N2 is now DF.
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 83
83
DF Preemption
Just before the backoff period expires, the current DF declares the candidate
router with the best Offer as the new DF. This is done via a Pass message
which includes the IDs and metrics of both the old and new DFs.
The current DF stops acting as a DF soon after the Pass is transmitted. The new
DF assumes the role of the DF as soon as it receives the Pass message. All
other routers on the link record the identity and the metric of the newly elected
DF.
RP
On RP discovery it sends Restarted
an Offer.
N1 N2
Offer 8 DF
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 84
84
RP
On RP discovery it sends
an Offer.
N1 N2
Acting DF responds with Winner 6 DF
Winner or Backoff
depending on metric
comparison.
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 85
85
Offer ? DF
N3 N4
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 86
86
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 87
87
Detecting DF Failures
Downstream Routers
RP RPF info no longer points to DF.
Non-Downstream Routers
PIM Neighbor timeout of DF.
Router response to a DF Failure
Routers resend their Offer messages
Triggers new DF election
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 88
88
DF Fails
The speed at which a new DF is elected after the original DF dies depends on
whether there are any downstream routers on the link.
For downstream routers the RPF neighbor (who is the DF at the same time) will
change and they will initiate the reelection by sending Offer messages. If the RP
is reachable through the link via another upstream router they will use an infinite
metric.
If no downstream routers are available the only way for other upstream routers
to detect a DF failure is by the timeout of the PIM neighbor information, which
will take longer.
DF metric changes:
Better metric:
May send Winner message with new metric.
Updates other routers.
Worse metric:
Sends 3 Winner messages with new metric.
Other routers can respond with a better Offer.
Non-DF metric changes:
Better metric than DF:
Send new Offer to trigger DF re -election.
Worse metric than DF:
No action is taken.
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 89
89
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 90
90
Additional Robustness
In order to ensure an additional robustness in DF election whenever a new PIM
neighbor is discovered by the current DF a Winner message is reannounced.
The proposal allows the DF to send periodic Winner messages for RPs serving
currently active groups as well.
DF Advantages
The implementation of PIM bidirectional mode where all the forwarding on a link
is centered around the Designated Forwarder ensures highly robust PIM SM
multicast networks and eliminates possible loops. All the multicast traffic from
the link towards the RP and in the opposite direction passes the DF.
Since the role of a Designated Router (DR) is handed to a Designated
Forwarder (DF) the placement of a DR is no more an issue. All (*,G) Joins are
originated (forwarded) via DF which again eliminates the possibilities for
forwarding loops.
Even if downstream routers on the link use customized unicast routes the
election of a DF ensures that all those routers know who the DF is and use it for
forwarding (*,G) Joins via it. This again eliminates multicast forwarding loops
that were possible in regular PIM SM due to misconfigurations.
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 92
92
Module12. ppt 1998 2001, Cisco Systems, Inc. All rights reserved. 8/21/2001 3:39 PM 93
93