Professional Documents
Culture Documents
Pgina 1 de 2
Finally, the IP Multicast Training materials have been updated with the latest information! Many of you have previously downloaded these materials for the purpose of self-training on IP Multicast. These new course materials have been updated and are even better than before. The training material includes lots of new topics not covered previously in the old course materials. Here's just a sample of some of the changes/additions to the material: Layer 2 Campus Design - Module 2 now contains material on the design issues relating to IP Multicast over campus networks including topics such as CGMP, IGMP Snooping, IGMPv3, mutlicast over ATM-LANE, and general Layer 2 "gotchas" that need to be avoided. Rendezvous Points - Module 6 is devoted to this topic and will help you answer that age old question, "Where do I put my RP?" This module covers the use of various RP techniques such Static RP's, Auto-RP and BSR as well as how to tune and debug these mechanisms. Advanced IP Multicast Features - Module 7 is a module that is chocked full of advanced multicast topics including, IP Multicast Helper, dealing with Rate-Limits, Admin. Scoping and many others. A real "must" read for people that are serious about extracting the absolute maximum performance out of their multicast network Multiprotocol BGP (MBGP) - Module 10 covers the use of MBGP for Inter-domain IP Multicast. Even if you are not already a BGP guru, you will find this module very helpful as it contains a short overview on BGP that will give the beginner to Inter-domain IP Multicasting the necessary background on BGP to get started. Multicast Source Discovery Protocol (MSDP) - Module 11 highlights MSDP and how it is currently being used in the Internet to interconnect independent PIM Sparse mode domains so that true Inter-domain IP Multicast can be accomplished. PIM Protocol Extension - Module 12 is an entirely new module that describes two of the latest extensions to the PIM protocol; Source-Specific Multicast (SSM) and Bidirectional PIM (Bidir). These two new extensions allow PIM to scale better in several different ways. These IP Multicast training modules have previously been used for internal Cisco training only. Due to the tremendous demand for this information, we have made this content available for "self-training" purposes by our customers. All of this material is copyrighted and may not be repackaged or resold for any commercial purposes without written permission from Cisco Systems. All modules are constantly being updated to improve their content and/or correct any mistakes in the material. You may wish to check this page from time to time to download updated versions of the material. The following training modules are all in Adobe PDF format. To view them, use Adobe Acrobat Reader. If file://D:\Lucho\xx\index.html 01/03/2003
Pgina 2 de 2
you don't have Acrobat Reader on your workstation you may download a free version from Adobe. Module Module1 Module2 Module3 Module 4 Module 5 Module 6 Module 7 Module 8 Module 9 Module 10 Module 11 Module 12 Title "Fundamentals of IP Multicasting" (1276 KB) "IP Multicasting at Layer 2" (1249 KB) "PIM Dense Mode" (936 KB) "Basic Multicast Debugging" (529 KB) "PIM Sparse Mode" (1599 KB) "Rendezvous Points" (971KB) "Advanced IP Multicast Features" (1319 KB) "DVMRP" (513 KB) "Interconnecting PIM & DVMRP Multicast Networks" (839 KB) "Multi-protocol BGP (MBGP)" (1139 KB) "Multicast Source Discovery Protocol (MSDP)" (1605 KB) "PIM Protocol Extensions" (1053 KB) Updated 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001 8/27/2001
file://D:\Lucho\xx\index.html
01/03/2003
Fundamentals of IP Multicast
Module 1
Module1. ppt
8/10/2001 3:45 PM
Module1.ppt
Module Objectives
Recognize when to use IP Multicast Identify the fundamental concepts involved in IP Multicasting Characterize the differences in various IP Multicast routing protocols
Module1. ppt
8/10/2001 3:45 PM
2 2
Module1.ppt
Agenda
Geekometer
Why Multicast Multicast Applications Multicast Service Model Multicast Distribution Trees Multicast Forwarding Multicast Protocol Basics Multicast Protocol Review
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
3 3
Module1.ppt
Why Multicast?
When sending same data to multiple receivers Better bandwidth utilization Less host/router processing Receivers addresses unknown
Module1. ppt
8/10/2001 3:45 PM
4 4
Module1.ppt
Unicast vs Multicast
Unicast
Host Router
Multicast
Host Router
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
5 5
Unicast transmission sends multiple copies of data, one copy for each receiver
Ex: host transmits 3 copies of data and network forwards each to 3 separate receivers Ex: host can only send to one receiver at a time
Module1.ppt
Multicast Advantages
Enhanced Efficiency : Controls network traffic and reduces server and CPU
loads
Optimized Performance: Eliminates traffic redundancy Distributed Applications: Makes multipoint applications possible
Example: Audio Streaming All clients listening to the same 8 Kbps audio
20
40
60
80
100
# Clients
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
6 6
Multicast transmission affords many advantages over unicast transmission in a one-to-many or many-to-many environment
Enhanced Efficiency: available network bandwidth is utilized more efficiently since multiple streams of data are replaced with a single transmission Optimized Performance: less copies of data require forwarding and processing Distributed Applications: multipoint applications will not be possible as demand and usage grows because unicast transmission will not scale Ex: traffic level and clients increase at a 1:1 rate with unicast transmission Ex: traffic level and clients do not increase at a greatly reduced rate with multicast transmission
Module1.ppt
Multicast Disadvantages
Multicast is UDP Based!!!
Best Effort Delivery: Drops are to be expected. Multicast applications
should not expect reliable delivery of data and should be designed accordingly. Reliable Multicast is still an area for much research. Expect to see more developments in this area.
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
8/10/2001 3:45 PM
7 7
Multicast Disadvantages
Most Multicast Applications are UDP based. This results in some undesirable sideeffects when compared to similar unicast, TCP applications. Best Effort Delivery results in occasional packet drops. Many multicast applications that operate in real-time (e.g. Video, Audio) can be impacted by these losses. Also, requesting retransmission of the lost data at the application layer in these sort of real-time applications is not feasible. Heavy drops on Voice applications result in jerky, missed speech patterns that can make the content unintelligable when the drop rate gets high enough. Moderate to Heavy drops in Video is sometimes better tolerated by the human eye and appear as unusual artifacts on the picture. However, some compression algorithms can be severely impacted by even low drop rates; causing the picture to become jerky or freeze for several seconds while the decompression algorithm recovers. No Congestion Control can result in overall Network Degradation as the popularity of UDP based Multicast applications grow. Duplicate packets can occasionally be generated as multicast network topologies change. Applications should expect occasional duplicate packets to arrive and should be designed accordingly.
Module1.ppt
IP Multicast Applications
Live TV and Radio Broadcast to the Desktop ing Multi e Learn cast Distanc F Data and F i l e T r a n s f er ile Re plica tion Corporate Broadcasts
ing nc e r nfe Co nd Wh o e ema iteb d D i V oar On d/C eo Vid olla bor atio RealReal -Time Data Delivery DeliveryFinancial n
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Training
8/10/2001 3:45 PM
8 8
Many new multipoint applications are emerging as demand for them grows
Ex: Real-time applications include live broadcasts, financial data delivery, whiteboard collaboration, and video conferencing Ex: Non-real-time applications include file transfer, data and file replication, and video-on-demand Note also that the latest version of Novell Netware uses Ipmc for file and print service announcements.see: http//developer.novell.com/research/appnotes/1999/march/02/index.htm
Module1.ppt
vataudio conferencing
PCM, DVI, GSM, and LPC4 compression
vicvideo conferencing
H.261 video compression
wbwhite board
Shared drawing tool Can import PostScript images Uses Reliable Multicast
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
9 9
Module1.ppt
sdrSession Directory
Module1. ppt
8/10/2001 3:45 PM
10 10
Module1.ppt
10
vatAudio Conferencing
Module1. ppt
8/10/2001 3:45 PM
11 11
Module1.ppt
11
vicVideo Conferencing
Module1. ppt
8/10/2001 3:45 PM
12 12
Module1.ppt
12
wbWhite Board
Module1. ppt
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.
Module1.ppt
13
Source code
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
14 14
Module1.ppt
14
RFC 1112 (Host Ext. for Multicast Support) Each multicast group identified by a class-D IP address Members of the group could be present anywhere in the Internet Members join and leave the group and indicate this to the routers Senders and receivers are distinct: i.e., a sender need not be a member Routers listen to all multicast addresses and use multicast routing protocols to manage groups
Module1. ppt
8/10/2001 3:45 PM
15 15
Addressing
Class D IP addresses (224-239) are dynamically allocated Multicast IP addresses represent receiver groups, not individual receivers
Group Membership
Receivers can be densely or sparsely distributed throughout the Internet Receivers can dynamically join/leave a multicast session at any time using IGMP to manage group membership within the routers Senders are not necessarily included in the multicast group they are sending to Many applications have the characteristic of receivers also becoming senders eg RTCP streams from IP/TV clients and Tibco RV
Multicast Routing
Group distribution requires packet distribution trees to efficiently forward data to multiple receivers Multicast routing protocols effectively direct multicast traffic along network paths Multicast Extension to Open Shortest Path First (MOSPF - 1584) Core Based Tree (CBT)
Module1.ppt
15
Module1. ppt
8/10/2001 3:45 PM
16 16
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.
Module1.ppt
16
IP Multicast Addressing
Dynamic Group Address Assignment
Historically accomplished using SDR application
Sessions/groups announced over well-known multicast groups Address collisions detected and resolved at session creation time Has problems scaling
8/10/2001 3:45 PM
17 17
Module1.ppt
17
IP Multicast Addressing
Module1. ppt
8/10/2001 3:45 PM
18 18
Module1.ppt
18
Module1. ppt
8/10/2001 3:45 PM
19 19
Multicast Forwarding
Unlike unicast forwarding which uses the destination address to make its forwarding decision, multicast forwarding uses the source address to make its forwarding decision.
Module1.ppt
19
Receiver 1
Module1. ppt
Receiver 2
8/10/2001 3:45 PM
20 20
Module1.ppt
20
Receiver 1
Module1. ppt
Receiver 2
8/10/2001 3:45 PM
21 21
Module1.ppt
21
D (RP)
(RP)
Receiver 1
Module1. ppt
Receiver 2
8/10/2001 3:45 PM
22 22
Module1.ppt
22
(RP)
Receiver 1
Module1. ppt
Receiver 2
8/10/2001 3:45 PM
23 23
Module1.ppt
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
8/10/2001 3:45 PM
24 24
Module1.ppt
24
DVMRP
Uses DVMRP Routing Table plus special Poison-Reverse mechanism to build tree.
MOSPF
Uses extension to OSPFs link state mechanism to build tree.
CBT
Uses existing Unicast Routing Table plus Join/Prune/Graft mechanism to build tree.
Module1. ppt
8/10/2001 3:45 PM
25 25
Distribution trees are built in a variety of ways, depending upon the multicast routing protocol employed
PIM utilizes the underlying unicast routing table (any unicast routing protocol) plus: Join: routers add their interfaces and/or send PIM -JOIN messages upstream to establish themselves as branches of the tree when they have interested receivers attached Prune: routers prune their interfaces and/or send PIM-PRUNE messages upstream to remove themselves from the distribution tree when they no longer have interested receivers attached Graft: routers send PIM-GRAFT messages upstream when they have a pruned interface and have already sent PIM-PRUNEs upstream, but receive an IGMP host report for the group that was pruned; routers must reestablish themselves as branches of the distribution tree because of new interested receivers attached DVMRP utilizes a special RIP -like multicast routing table plus: Poison-Reverse: a special metric of Infinity (32) plus the originally received metric, used to signal that the router should be placed on the distribution tree for the source network. Prunes & Grafts: routers send Prunes and Grafts up the distribution similar to PIM-DM. MOSPF utilizies the underlying OSPF unicast routing protocol's link state advertisements to build (S,G) trees Each router maintains an up-to-date image of the topology of the entire network CBT utilizes the underlying unicast routing table and the Join/Prune/Graft mechanisms (much like PIM -SM)
Copyright 1999-2001, Cisco Systems, Inc.
Module1.ppt
25
Multicast Forwarding
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
Module1.ppt
26
Module1. ppt
8/10/2001 3:45 PM
27 27
Module1.ppt
27
If the RPF check succeeds, the datagram is forwarded If the RPF check fails, the datagram is typically silently discarded When a datagram is forwarded, it is sent out each interface in the outgoing interface list Packet is never forwarded back out the RPF interface!
Module1. ppt
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
Module1.ppt
28
Source 151.10.3.21
Module1. ppt
8/10/2001 3:45 PM
29 29
Module1.ppt
29
S1 E0
X
S0 S2
Module1. ppt
8/10/2001 3:45 PM
30 30
Module1.ppt
30
Packet Arrived on Correct Interface! Forward out all outgoing interfaces. (i. e. down the distribution tree)
Module1. ppt
8/10/2001 3:45 PM
31 31
Module1.ppt
31
TTL Thresholds
What is a TTL Threshold?
A TTL Threshold may be set on a multicast router interface to limit the forwarding of multicast traffic to outgoing packets with TTLs greater than the Threshold.
Module1. ppt
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.
Module1.ppt
32
TTL Thresholds
TTL-Threshold = 16 S1 E0
S2 TTL-Threshold = 64
TTL-Threshold = 0
Module1. ppt
TTL-Threshold Example
In the above example, the interfaces have been configured with the following TTL Thresholds: S1: TTL -Threshold = 16 E0: TTL -Threshold = 0 (none) S2: TTL -Threshold = 64 An incoming Multicast packet is received on interface S0 with a TTL of 24. The TTL is decremented to 23 by the normal router IP packet processing. The outgoing interface list for this Group contains interfaces S1, E0 & S2. The TTL -Threshold check is performed on each outgoing interface as follows: S1: TTL (23) > TTL -Threshold (16). FORWARD E0: TTL (23) > TTL -Threshold (0). FORWARD
S0
8/10/2001 3:45 PM
33 33
Module1.ppt
33
Company ABC
Eng
Mkt
TTL-Threshold = 16
TTL-Threshold = 128
Module1. ppt
8/10/2001 3:45 PM
34 34
TTL-Threshold Boundaries
TTL-Thresholds may be used as boundaries around portions of a network to prevent the entry/exit of unwanted multicast traffic. This requires multicast applications to transmit their multicast traffic with an initial TTL value set so as to not cross the TTL -Threshold boundaries. In the example above, the Engineering or Marketing departments can prevent department related multicast traffic from leaving their network by using a TTL of 15 for their multicast sessions. Similarlly, Company ABC can prevent private multicast traffic from leaving their network by using a TTL of 127 for their multicast sessions.
Module1.ppt
34
Administrative Boundaries
239.x.x.x multicasts
Serial0
239.x.x.x multicasts
Serial1
Module1. ppt
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.
Module1.ppt
35
Administrative Boundaries
Company ABC
LA Campus
NYC Campus
239.128.0.0/16
239.129.0.0/16
Module1. ppt
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.
Module1.ppt
36
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
37
? MOSPF (RFC 1584) Proposed Standard ? PIM-DM (Internet-draft) ? CBT (Internet-draft) ? PIM-SM (RFC 2362) Proposed Standard
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
38 38
Module1.ppt
38
Dense-Mode Protocols
DVMRP - Distance Vector Multicast Routing Protocol MOSPF - Multicast OSPF PIM DM - Protocol Independent Multicasting (Dense Mode)
Module1. ppt
8/10/2001 3:45 PM
39 39
Module1.ppt
39
DVMRP Overview
Dense Mode Protocol
Distance vector-based
Similar to RIP Infinity = 32 hops Subnet masks in route advertisements
8/10/2001 3:45 PM
40 40
Module1.ppt
40
A
mrouted 1 33 1 mrouted 33
B
mrouted 1 2
X
mrouted 3 mrouted 34 35
mrouted 2 2
E
3
35
Y
mrouted
n m
Route for source network of metric n Poison reverse (metric + infinity) sent to upstream parent router. Router depends on parent to receive traffic for this source. Resulting Truncated Broadcast Tree for Source Network
41 41
Module1. ppt
8/10/2001 3:45 PM
Module1.ppt
41
Both B & C have routes to network S1. To avoid duplicates, only one router can be Designated Forwarder for network S1. Router with best metric is elected as the Designated Forwarder. Lowest IP address used as tie-breaker. Router C wins in this example.
mrouted
mrouted 2 2
8/10/2001 3:45 PM
42 42
Module1.ppt
42
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
8/10/2001 3:45 PM
43 43
Module1.ppt
43
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Source Network S2
8/10/2001 3:45 PM
44 44
Advantages of TBTs
The advantage of TBTs is that the initial flooding of multicast traffic throughout the DVMRP network is limited to flowing down the branches of the TBT. This insures that there are no duplicate packets sent as a result of parallel paths in the network.
Disadvantages of TBTs
The disadvantage of using TBTs is that it requires separate DVMRP routing information to be exchanged throughout the entire network. (Unlike other multicast protocols such as PIM that make use of the existing unicast routing table and do not have to exchange additional multicast routing data. Additionally, because DVMRP is based on a RIP model, it has all of the problems associated with a Distance-Vector protocol including, count-to-infinity, holddown, periodic updates. One has to ask oneself, Would I recommend someone build a unicast network based on RIP today? The answer is of course not, protocols like OSPF, IS-IS, and EIGRP have long since superseded RIP in robustness and scalability. The same is true of DVMRP.
Module1.ppt
44
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
45 45
DVMRP Example
In this example we see source S has begun to transmit multicast traffic to group G. Initially, the traffic (shown by the solid arrows) is flooded to all routers in the network down the Truncated Broadcast Tree (indicated by the dashed arrows) and is reaching Receiver 1.
Module1.ppt
45
A
mrouted Prune
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
46 46
Module1.ppt
46
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Prune
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
47 47
Module1.ppt
47
A
mrouted
B
mrouted
X
mrouted Prune
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
48 48
Module1.ppt
48
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
49 49
Module1.ppt
49
DVMRP Evaluation
Widely used on the MBONE (being phased out) Significant scaling problems
Slow ConvergenceRIP-like behavior Significant amount of multicast routing state information stored in routers(S,G) everywhere No support for shared trees Maximum number of hops < 32
Module1. ppt
8/10/2001 3:45 PM
50 50
Appropriate for large number of densley distributed receivers located in close proximity to source Widely used, oldest multicast routing protocol Significant scaling problems
Protocol limits maximum number of hops to 32 and requires a great deal of multicast routing state information to be retained
Module1.ppt
50
Group membership LSAs are flooded throughout the OSPF routing domain so MOSPF routers can compute outgoing interface lists Uses Dijkstra algorithm to compute shortest-path tree
Separate calculation is required for each (S Net, G) pair
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
51 51
Dijkstra Algorithm
Uses Dijkstra algorithm to compute shortest-path tree for every sourcenetwork/group pair!!!
Module1.ppt
51
MABR1 Area 1
MABR2 Area 2
Membership LSAs
MB
Membership LSAs
MA
Module1. ppt
MB
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
MA
8/10/2001 3:45 PM
52 52
Module1.ppt
52
MABR1
MABR2 Area 2
MB
MA
Module1. ppt
M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
M A (S2 , A)
8/10/2001 3:45 PM
53 53
Intra-Area Multicast
Once all routers within the area have learned where all members are in the network topology, it is possible to construct Source-network trees for multicast traffic forwarding.
Example
In the above example, Source S1 in Area 1 begins sending multicast traffic to Group B. As this data reaches the the routers in the area, each runs a Dijkstra calculation and computes a Shortest Path Tree rooted at the network for S1 and that spans all the members of Group B. The results of these calculations are used to forward the (S1, B) traffic as seen in Area 1 above. In Area 2, Source S2 begins sending multicast traffic to Group A. Again, the routers in the area use the Group-Membership information in their MOSPF database to run a Dijkstra calculation for the source network where S2 resides and create a Shortest Path Tree for this traffic flow. The results are then used to forward (S2, A) traffic as shown. Notice that the routers in Area 2 are not aware of the member of Group A in Area 1 because Membership LSAs are not flooded between these two areas. This InterArea traffic flow is handled by another mechanism that is described in the next few pages.
Module1.ppt
53
Area 0
(*, *)
(*, *)
MABR1 Area 1
MABR2 Area 2
MB
MA
Module1. ppt
M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
M A (S2 , A)
8/10/2001 3:45 PM
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.
Module1.ppt
54
MABR1 Area 1
MABR2 Area 2
MB
MA
Module1. ppt
M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
M A (S2 , A)
8/10/2001 3:45 PM
55 55
Module1.ppt
55
(GA )
Summarized Membership LSA
MABR1 Area 1
MABR2 Area 2
Membership LSAs
MB
Membership LSAs
MA
Module1. ppt
M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
M A (S2 , A)
8/10/2001 3:45 PM
56 56
Module1.ppt
56
MABR1 Area 1
MABR2 Area 2
MB
MA
Module1. ppt
M B (S1 , B)
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
M A (S2 , A)
8/10/2001 3:45 PM
57 57
Module1.ppt
57
(*, *)
(*, *)
MABR1 Area 1
MABR2 Area 2
(S1 , B)
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
(S2 , A)
8/10/2001 3:45 PM
58 58
Module1.ppt
58
MASBR
External AS
Summarized Membership LSA
(GA , GB)
(GA )
MABR1 Area 1
MABR2 Area 2
Membership LSAs
MB
Membership LSAs
MA
Module1. ppt
MB
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
MA
8/10/2001 3:45 PM
59 59
Inter-Domain Traffic
Inter-domain multicast traffic flow basically follows the same mechanisms that were used for Inter-Area traffic flows. Summary Membership LSAs inform the routers in the backbone of which MABRs has members of which groups.
Module1.ppt
59
MABR1 Area 1
MABR2 Area 2
MB
MA
Module1. ppt
MB
1998 2001, Cisco Systems, Inc. All rights reserved.
MA
MA
8/10/2001 3:45 PM
60 60
Module1.ppt
60
MASBR
External AS
(*, *)
(*, *)
MABR1 Area 1
MABR2 Area 2
(S1 , B)
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
(S2 , A)
8/10/2001 3:45 PM
61 61
Module1.ppt
61
MOSPF Evaluation
Does not flood multicast traffic everywhere to create state, Uses LSAs and the link-state database Protocol dependentworks only in OSPF-based networks Significant scaling problems
Dijkstra algorithm run for EVERY multicast (S Net, G) pair! Dijkstra algorithm rerun when:
Group Membership changes Line-flaps
8/10/2001 3:45 PM
62 62
Appropriate for use within single routing domain Requires OSPF as underlying unicast routing protocol Significant scaling problems
Frequent flooding of link-state/membership information hinders performance Router CPU demands grow rapidly to keep track of current network topology (source-group pairs) Dijkstra algorithm must be run for every single multicast source Volatility of multicast groups can be lethal
Module1.ppt
62
PIM-DM
Protocol Independent
Supports all underlying unicast routing protocols including: static, RIP, IGRP, EIGRP, IS-IS, BGP, and OSPF
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
Appropriate for
Small implementations and pilot networks
Module1.ppt
63
Initial Flooding
Source
Multicast Packets
Receiver
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
64 64
Module1.ppt
64
Source
8/10/2001 3:45 PM
65 65
Module1.ppt
65
Source
Multicast Packets
Receiver
8/10/2001 3:45 PM
66 66
Module1.ppt
66
Module1. ppt
8/10/2001 3:45 PM
67 67
Module1.ppt
67
Source
Interface previously Pruned by Assert Process
RPF Interface
Module1. ppt
8/10/2001 3:45 PM
68 68
Module1.ppt
68
RPF Interface
Module1. ppt
8/10/2001 3:45 PM
69 69
Module1.ppt
69
Module1. ppt
8/10/2001 3:45 PM
70 70
Module1.ppt
70
Initial Flow
Duplicate Traffic
Receiver
Receiver
Multicast Packets
Source
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
71 71
Module1.ppt
71
Sending Asserts
Loser
Receiver
Receiver
Winner
8/10/2001 3:45 PM
72 72
Module1.ppt
72
Receiver
Receiver
Winner
Multicast Packets
Source
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
73 73
Module1.ppt
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
74
PIM-DM Evaluation
Most effective for small pilot networks Advantages:
Easy to configuretwo commands Simple flood and prune mechanism
Potential issues...
Inefficient flood and prune behavior Complex Assert mechanism Mixed control and data planes
Results in (S, G) state in every router in the network Can result in non-deterministic topological behaviors
8/10/2001 3:45 PM
75 75
Module1.ppt
75
Sparse-Mode Protocols
PIM SM- Protocol Independant Multicasting (Sparse Mode) CBT - Core Based Trees
Module1. ppt
8/10/2001 3:45 PM
76 76
Module1.ppt
76
Appropriate for
Wide scale deployment for both densely and sparsely populated groups in the enterprise Optimal choice for all production networks regardless of size and membership density.
Module1. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 3:45 PM
77 77
Module1.ppt
77
RP
Module1. ppt
8/10/2001 3:45 PM
78 78
Module1.ppt
78
Source
RP
(unicast)
Receiver
Module1. ppt
8/10/2001 3:45 PM
79 79
Module1.ppt
79
Source
RP
(S, G) Register (S, G) Joins Shared Tree Source Tree (S, G) Register-Stop
(unicast)
(unicast)
Receiver
Module1. ppt
8/10/2001 3:45 PM
80 80
Module1.ppt
80
Source
RP
Source traffic flows natively along SPT to RP. From RP, traffic flows down the Shared Tree to Receivers.
Module1. ppt
8/10/2001 3:45 PM
81 81
Module1.ppt
81
Source
RP
Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes Additional (S, G) State is created along new part of the Source Tree. Receiver Additional (S, G) State is created along along the Shared Tree to prune off (S, G) traffic.
Module1. ppt
8/10/2001 3:45 PM
82 82
Module1.ppt
82
Source
RP
(S, G) Traffic flow is now pruned off of the Shared Tree and is flowing to the Receiver via the SPT.
Module1. ppt
8/10/2001 3:45 PM
83 83
Module1.ppt
83
Source
RP
(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.
Module1.ppt
8/10/2001 3:45 PM
84 84
Module1.ppt
84
Source
RP
(S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree.
Module1.ppt
8/10/2001 3:45 PM
85 85
Module1.ppt
85
PIM-SM FFF
Module1. ppt
8/10/2001 3:45 PM
86 86
Module1.ppt
86
PIM-SM Evaluation
Module1. ppt
8/10/2001 3:45 PM
87 87
Module1.ppt
87
CBT Overview
Constructs single, shared delivery tree (not source -based) for multicast group members
Traffic is sent and received over same tree, regardless of source(s) Reduced amount of multicast state information stored in routers
8/10/2001 3:45 PM
88 88
Module1.ppt
88
CBT Evaluation
Module1. ppt
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
Module1.ppt
89
Protocol Summary
CONCLUSION
Virtually all production networks should be configured to run PIM in Sparse mode!
Module1. ppt
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.
Module1.ppt
90
Module1.ppt
91
Module1.ppt
91
IP Multicasting at Layer 2
Module 2
Module2. ppt
8/9/2001 4:20 PM
Module2.ppt
Module Objectives
Understand Layer 2 Multicast Addressing Identify the purpose of IGMP Recognize the difference between v1, v2 & v3 of the IGMP protocol Identify issues in IGMP v1-v2 Interoperation Identify potential solutions to L2 Multicast Frame Switching problems
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
2 2
Module2.ppt
Module Agenda
MAC Layer Multicast Addresses IGMPv1 IGMPv2 IGMP v1-v2 Interoperability IGMPv3 L2 Multicast Frame Switching
Module2. ppt
8/9/2001 4:20 PM
3 3
Module2.ppt
All systems on this subnet All routers on this subnet DVMRP routers
8/9/2001 4:20 PM
4 4
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
Module2.ppt
239.255.0.1
5 Bits Lost
01-00-5e-7f-00-01
25 Bits 48 Bits 23 Bits
Module2. ppt
8/9/2001 4:20 PM
5 5
A bit of History
It turns out that this loss of 5 bits worth of information was not originally intended. When Dr. Steve Deering was doing his seminal research on IP Multicast, he approached his advisor with the need for 16 OUIs to map all 28 bits worth of Layer 3 IP Multicast address into unique Layer 2 MAC addresses. Note: An OUI (Organizationally Unique Identifier) is the high 24 bits of a MAC address that is assigned to an organization by the IEEE. A single OUI therefore provides 24 bits worth of unique MAC addresses to the organization. Unfortunately, at that time the IEEE charged $1000 for each OUI assigned which meant that Dr. Deering was requesting that his advisor spend $16,000 so he could continue his research. Due to budget constraints, the advisor agreed to purchase a single OUI for Dr. Deering. However, the advisor also chose to reserve half of the MAC addresses in this OUI for other graduate research projects and granted Dr. Deering the other half. This resulted in Dr. Deering having only 23 bits worth of MAC address space with which to map 28 bits of IP Multicast addresses. (Its too bad that it wasnt known back then how popular IP Multicast would become. If they had, Dr. Deering might have been able to pass the hat around to interested parties and collected enough money to purchase all 16 OUIs. :-) )
Copyright ? ?1998-2001 Cisco Systems, Inc.
Module2.ppt
0x0100.5E01.0101
8/9/2001 4:20 PM
6 6
Module2.ppt
224.x.x.x c0-00-00-04-00-00
(Shown in Token Ring, non-canonical format)
224.x.x.x ff-ff-ff-ff-ff-ff
8/9/2001 4:20 PM
7 7
0xFFFF.FFFF.FFFF
RUN AWAY ! ! !
8/9/2001 4:20 PM
8 8
Module2.ppt
Module2. ppt
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
IGMP
How hosts tell routers about group membership Routers solicit group membership from directly connected hosts RFC 1112 specifies first version of IGMP RFC 2236 specifies current version of IGMP IGMP v3 enhancements Supported on UNIX systems, PCs, and MACs
Module2. ppt
8/9/2001 4:20 PM
10 10
IGMP
The primary purpose of IGMP is to permit hosts to commincate their desire to receive multicast traffic to the IP Multicast router(s) on the local network. This, in turn, permits the IP Multicast router(s) to Join the specified multicast group and to begin forwarding the multicast traffic onto the network segment. The initial specification for IGMP (v1) was documented in RFC 1112, Host Extensions for IP Multicasting. Since that time, many problems and limitations with IGMPv1 have been discovered. This has lead to the development of the IGMPv2 specification which was ratified in November, 1997 as RFC 2236. Even before IGMPv2 had been ratified, work on the next generation of the IGMP protocol, IGMPv3, had already begun. However, the IGMPv3 specification is still in the working stage and has not been implemented by any v endors.
Module2.ppt
10
IGMPv1
Membership Reports
IGMP report sent by one host suppresses sending by others Restrict to one report per group per LAN Unsolicited reports sent by host, when it first joins the group
Module2. ppt 8/9/2001 4:20 PM
11 11
Report Suppression
Report suppression is used among group members so that all members do not have to respond to a query. This saves CPU and bandwidth on all systems. The rule in multicast membership is that as long as one member is present, the group must be forwarded onto that segment. Therefore, only one member present is required to keep interest in a given group so report suppression is efficient.
TTL
Since Membership Query and Report packets only have local significance, the TTL of these packets are always set to 1. This is also so they will not be accidentally forwarded off of the local subnet and cause confusion on other subnets.
Module2.ppt
11
IGMPv1Packet Format
4 Ver 7 Type Unused 15 23 Checksum 31
Group Address
Ver: Code Version = 1 Type: 1 = Host Membership Query 2 = Host Membership Report Group Address: Multicast Group Address
Module2. ppt
8/9/2001 4:20 PM
12 12
Version
is the IGMP version and should be 0x1 in IGMPv1. This field has been merged with the Type field in IGMPv2 and eliminated.
Type
is the IGMP message type. 0x1 = Host Membership Query 0x2 = Host Membership Report This field has been expanded into an 8 bit field in IGMPv2 .
Group
is the Multicast Group address being specified for reports.
Module2.ppt
12
IGMPv1Joining a Group
H1 H2 224.1.1.1 H3
Report
IGMPv1
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.
Module2.ppt
13
IGMPv1General Queries
H1 H2 H3
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.
Module2.ppt
14
IGMPv1Maintaining a Group
224.1.1.1 H1 224.1.1.1 H2 224.1.1.1 H3
X
Suppressed #3 Report #2
X
Suppressed #3 Query to 224.0.0.1 IGMPv1 #1
#1 #2 #3
Module2. ppt
Router sends periodic queries One member per group per subnet reports Other members suppress reports
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
15 15
Query-Response Process
The router multicasts periodic IGMPv1 Membership Queries to the All-Hosts (224.0.0.1) group address. Only one member per group responds with a report to a query. This is to save bandwidth on the subnet network and processing by the hosts. This is process is called Response Suppression. (See below.)
Module2.ppt
15
IGMPv1Leaving a Group
H1 H2 H3
Module2. ppt
Router sends periodic queries Hosts silently leave group Router continues sending periodic queries No Reports for group received by router Group times out
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
16 16
IGMPv1 Leaves
There was no special Leave mechanism defined in Version 1 of IGMP. Instead, IGMPv1 hosts leave a group "passively" or "quietly" at any time without any notification to the router. This is not a problem if there are multiple member present because the multicast flow still must be delivered to the segment. However, when the member leaving is the last member, there will be a period when the router continues to forward the multicast traffic onto the segment needlessly since there are no members left. It was up to the IGMP Query router to timeout the Group after several Query Intervals pass without a response for a Group. This is inefficient - especially if the number of groups and/or the traffic in these groups is high.
Module2.ppt
16
IGMPv2
RFC 2236
Group-specific query
Router sends Group-specific queries to make sure there are no members present before stopping to forward data for the group for that subnet
Module2. ppt
8/9/2001 4:20 PM
IGMPv2
As a result of some of the limitations discovered in IGMPv1, work was begun on IGMPv2 in an attempt to remove these limitations. Most of the changes between IGMPv1 and IGMPv2 are primarily to address the issues of Leave and Join latencies as well as address ambiguities in the original protocol specification. (IGMPv2 is almost to standard status.) The following sections define some of the more significant changes.
Module2.ppt
17
IGMPv2 (cont.)
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.
Module2.ppt
18
IGMPv2Packet Format
7 Type Max. Resp. Time Group Address 15 Checksum 31
Type: 0x11 = Membership Query 0x12 = Version 1 Membership Report 0x16 = Version 2 Membership Report 0x17 = Leave Group Max. Resp. Time max. time before sending a responding report in 1/10 secs. (Default = 10 secs) Group Address: Multicast Group Address (0.0.0.0 for General Queries)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
19 19
Type
In IGMPv2, the old 4 bit Version field was merged with the old 4 bit Type field to create a new 8 bit Type field. By assigning IGMPv2 type codes 0x11 and 0x12 as the Membership Query (V1 & V2) and the V1 Membership Report respectively, backwards compatibility of IGMP v1 and v2 packet formats was maintained.
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.
Module2.ppt
19
IGMPv2Joining a Group
1.1.1.10 H1 1.1.1.11 224.1.1.1 H2 1.1.1.12 H3
Joining member sends report to 224.1.1.1 immediately upon joining (same as IGMPv1)
20 20
Module2. ppt
8/9/2001 4:20 PM
Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in an unsolicited report indicating their interest. This reduces join latency for the end system joining if no other members are present.
Module2.ppt
20
IGMPv2Joining a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3
rtr-a>show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime 224.1.1.1 Ethernet0 6d17h
Expires 00:02:31
Module2. ppt
8/9/2001 4:20 PM
21 21
Module2.ppt
21
IGMPv2Querier Election
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3
1.1.1.1
rtr-a
Intially all routers send out a Query Router w/lowest IP address elected querier Other routers become Non-Queriers
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
22 22
Querier Election
In IGMPv1 there was no formal IGMP querying router election process in within IGMPv1 itself - it was left up to the multicast routing protocol and different protocols used different mechanisms. This would often result in multiple queriers on a single multiaccess network. With the definition of IGMPv2 a formal querying router election process was specified within the IGMPv2 protocol itself. In IGMPv2 each router on a multiaccess network will initially assume it is the querier and begin sending queries. Each router will see the queries from the other IGMPv2 routers and will examine the IP address of these queries. All IGMPv2 routers will then defer to the router with the lowest IP address. In other words, the IGMPv2 router with the lowest IP address will become the querying router. Finally, if the currently elected Query Router fails to issue a query within a specified time limit, a timer in the other IGMPv2 routers will time-out and cause them to re-initiate the Query Election process.
Query Interval
Membership queries are sent every 60 seconds (default).
Module2.ppt
22
IGMPv2Querier Election
Determining which router is the IGMP Querier
rtr-a>show rtr-a>show ip ip igmp igmp interface interface e0 e0 Ethernet0 Ethernet0 is is up, up, line line protocol protocol is is up up Internet address is 1.1.1.1, Internet address is 1.1.1.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current Current IGMP IGMP version version is is 22 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 60 60 seconds seconds IGMP IGMP querier querier timeout timeout is is 120 120 seconds seconds IGMP max query response time IGMP max query response time is is 10 10 seconds seconds Inbound IGMP access group is Inbound IGMP access group is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 1.1.1.1 1.1.1.1 (this (this system) system) IGMP IGMP querying querying router router is is 1.1.1.1 1.1.1.1 (this (this system) system) Multicast groups joined: 224.0.1.40 224.2.127.254 Multicast groups joined: 224.0.1.40 224.2.127.254
Module2. ppt
8/9/2001 4:20 PM
23 23
Module2.ppt
23
IGMPv2Maintaining a Group
1.1.1.10 224.1.1.1 1.1.1.11 224.1.1.1 H2 224.1.1.1 1.1.1.12 H1 H3
X
Suppressed 1.1.1.1
Suppressed
Report
Query
IGMPv2
Router sends periodic queries One member per group per subnet reports Other members suppress reports
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
24 24
Query-Response Process
The router multicasts periodic IGMPv1 Membership Queries to the All-Hosts (224.0.0.1) group address. Only one member per group responds with a report to a query. This is to save bandwidth on the subnet network and processing by the hosts. This is process is called Response Suppression. (See section below.)
Module2.ppt
24
IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3
1.1.1.1 rtr-a
Module2. ppt
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.)
Module2.ppt
25
IGMPv2Leaving a Group
1.1.1.10 H1 224.1.1.1 Leave to #1 224.0.0.2 1.1.1.11 H2 224.1.1.1 Report to #3 224.1.1.1 1.1.1.1 rtr-a Group Specific Query to 224.1.1.1 #2 1.1.1.12 H3
Module2. ppt
H2 leaves group; sends Leave message Router sends Group specific query A remaining member host sends report Group remains active
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
26 26
IGMPv2 Leaves
In IGMPv1, hosts would leave passively - i.e.. they do not explicitly say they are leaving - they just stop reporting. However, IGMPv2 has explicit Leave Group messages. When the IGMPv2 Query router receives a Leave Message, it responds by sending a Group Specific Query for the associated group to see if there are still other hosts wishing to receive traffic for the group. This process helps to reduce overall Leave Latency. When CGMP is in use, the IGMPv2 Leave Message mechanism also helps the router to better manage the CGMP state in the switch. This also improves the leave latency for the specific host at layer 2. (Note: Due to the wording of the current IGMPv2 draft specification, hosts may chose to NOT send Leave messages if they are not the last host to leave the group. This can adversely affect CGMP performance.)
Example :
H2 and H3 are members of group 224.1.1.1 #1 - H2 leaves #2 - Router sends group specific query to see if any other group members are present. #3 - H3 hasnt left yet so it responds with a Report message. Router keeps sending multicast for 224.1.1.1 since there is >= 1 member present
Module2.ppt
26
IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3
1.1.1.1 rtr-a
Module2. ppt
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.
Module2.ppt
27
IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 224.1.1.1 Leave to #1 224.0.0.2 1.1.1.1 rtr-a Group Specific Query to 224.1.1.1 #2 1.1.1.12 H3
Last host leaves group; sends Leave message Router sends Group specific query No report is received Group times out
1998 2001, Cisco Systems, Inc. All rights reserved.
Module2. ppt
8/9/2001 4:20 PM
28 28
Module2.ppt
28
IGMPv2Leaving a Group
1.1.1.10 H1 1.1.1.11 H2 1.1.1.12 H3
1.1.1.1 rtr-a
Module2. ppt
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.
Module2.ppt
29
IGMPv2Response Tuning
Query Query
Report suppression mechanism tends to spread Reports out over the entire Query Response Interval
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
30 30
Module2.ppt
30
IGMPv2Response Tuning
Query Query Query
Query
Query
Query
Increasing the Query Response Interval will spread out Reports; decreasing Burstiness.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
31 31
Module2.ppt
31
IGMPv2Response Tuning
Module2. ppt
8/9/2001 4:20 PM
32 32
Module2.ppt
32
IGMPv2Response Tuning
Verifying IGMPv2 Response Tuning Values
jabber>show jabber>show ip ip igmp igmp interface interface e0 e0 Ethernet0 Ethernet0 is is up, up, line line protocol protocol is is up up Internet Internet address address is is 10.1.3.1, 10.1.3.1, subnet subnet mask mask is is 255.255.255.0 255.255.255.0 IGMP is enabled on interface IGMP is enabled on interface Current Current IGMP IGMP version version is is 22 CGMP CGMP is is disabled disabled on on interface interface IGMP IGMP query query interval interval is is 120 120 seconds seconds IGMP IGMP querier querier timeout timeout is is 240 240 seconds seconds IGMP max query response time IGMP max query response time is is 20 20 seconds seconds Inbound IGMP access group is Inbound IGMP access group is not not set set Multicast Multicast routing routing is is enabled enabled on on interface interface Multicast Multicast TTL TTL threshold threshold is is 00 Multicast Multicast designated designated router router (DR) (DR) is is 10.1.3.1 10.1.3.1 (this (this system) system) IGMP IGMP querying querying router router is is 10.1.3.1 10.1.3.1 (this (this system) system) Multicast groups joined: 224.0.1.40 224.2.127.254 Multicast groups joined: 224.0.1.40 224.2.127.254
Module2. ppt
8/9/2001 4:20 PM
33 33
Module2.ppt
33
Module2. ppt
8/9/2001 4:20 PM
34 34
Module2.ppt
34
H2
IGMPv2
H3
Router A
8/9/2001 4:20 PM
35 35
Module2.ppt
35
8/9/2001 4:20 PM
36 36
Module2.ppt
36
Module2. ppt
8/9/2001 4:20 PM
37 37
Module2.ppt
37
IGMPv3
draft-ietf-idmr-igmp-v3-??.txt
In EFT
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
38
IGMPv3
New Membership Report address
224.0.0.22 (IGMPv3 Routers)
All IGMPv3 Hosts send reports to this address
Instead of the target group address as in IGMPv1/v2
All IGMPv3 Routers listen to this address Hosts do not listen or respond to this address
No Report Suppression
All Hosts on wire respond to Queries Response Interval may be tuned over broad range
Useful when large numbers of hosts reside on subnet
Module2. ppt
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.
Module2.ppt
39
7 Type = 0x11
31 Checksum
S QRV
QQIC
8/9/2001 4:20 PM
40 40
Type
The same IGMPv2 type code 0x11 is used as the IGMPv3 Membership Query Type code.
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.
Number of Sources
The number of Source Addresses in the Group-and-Source-Specific Query.
Copyright ? ?1998-2001 Cisco Systems, Inc.
Module2.ppt
40
Reserved
Multicast Group Address Group Record [1] Source Address [1] Source Address [2] . . . Source Address [N] Auxilliary Data Group Record [M]
# of Group Records (M) Number of Group Records in Report Group Records 1 - M Group address plus list of zero or more sources to Include/Exclude (See Group Record format)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Record Type Include, Exclude, Chg-to-Include, Chg-to-Exclude, Add, Remove # of Sources (N) Number of Sources in Record Source Address 1- N Address of Source
8/9/2001 4:20 PM
41 41
# of Group Records
Indicates the number of Group records that are contained in the Membership Report. IGMPv3 Membership Reports can contain IGMP state on a number of Groups and Sources within the group. The source information specifies which Sources to Include or Exclude.
Module2.ppt
41
IGMPv3 Example
Source = 1.1.1.1 Group = 224.1.1.1 R1 R2 Source = 2.2.2.2 Group = 224.1.1.1
H1 wants to receive only S = 1.1.1.1 and no other. With IGMP, specific sources can be joined. S = 1.1.1.1 in this case R3 IGMPv3: Join 224.1.1.1 Include: 1.1.1.1 H1 - Member of 224.1.1.1
Module2. ppt
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,.
Module2.ppt
42
IGMPv3Joining a Group
1.1.1.10 H1
v3 Report (224.0.0.22)
1.1.1.11 H2
Group: 224.1.1.1 Exclude: <empty>
1.1.1.12 H3
1.1.1.1 rtr-a
Module2. ppt
8/9/2001 4:20 PM
Asynchronous Joins
Members joining a group do not have to waited for a query to join; they send in an unsolicited IGMPv3 Membership Report indicating their interest. This reduces join latency for the end system joining if no other members are present. In the example above, Host 2 is joining multicast group 224.1.1.1 and is willing to receive any and all sources in this group.
Module2.ppt
43
1.1.1.11 H2
Group: 224.1.1.1 Include: 10.0.0.1
1.1.1.12 H3
1.1.1.1 rtr-a
IGMPv3 Report contains desired source(s) in the Include list. Only Included source(s) are joined.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
44 44
Module2.ppt
44
1.1.1.11 H2
Group: 224.1.1.1 Exclude: 7.7.7.7
1.1.1.12 H3
1.1.1.1 rtr-a
IGMPv3 Report contains undesired source(s) in the Exclude list. All sources except Excluded source(s) are joined.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
45 45
Module2.ppt
45
IGMPv3Maintaining State
1.1.1.10 H1
v3 Report (224.0.0.22) v3 Report (224.0.0.22)
1.1.1.11 H2
1.1.1.12 H3
v3 Report (224.0.0.22)
1.1.1.1
Query
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
46
PIM
Multicast M
8/9/2001 4:20 PM
47 47
L2 Multicast Switching
For most L2 Switches, Multicast traffic is normally treated like an unknown MAC address or Broadcast frame which causes the frame to be flooded out every port within a VLAN at rates of over 1 Mbps. This is fine for unknowns and broadcasts but as we have seen earlier, IP Multicast hosts may join and be interested in only specific multicast groups. Again, on most L2 Switches, all this traffic is forwarded out all ports resulting in wasted bandwidth on both the segments and on the end stations. One way around this on Catalyst Switches is using the Command Line Interface to program the switch manually to associate a multicast MAC address with say ports 5,6,7 so only ports 5,6,and 7 receive the multicast traffic destined for the multicast group. This works fine but again we know IP Multicast hosts dynamically join and leave groups using IGMP to signal to the Multicast Router. This static way of entering the multicast information is not very scaleable. Dynamic configuration of the Switches forwarding tables would be a better idea, and cut down on user administration.
Module2.ppt
47
Impact on switch:
Must process ALL Layer 2 multicast packets Admin. load increases with multicast traffic load Requires special hardware to maintain throughput
IGMP
IGMP
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
48 48
Module2.ppt
48
CPU
Switching Engine
CAM Table
2
MAC Address 0000.6503.1d0e Port 5
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
49 49
Module2.ppt
49
LAN Switch
CPU
Switching Engine
CAM Table
2
MAC Address Ports
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
50 50
Module2.ppt
50
LAN Switch
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2
Entry Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
51 51
Module2.ppt
51
LAN Switch
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
52 52
Module2.ppt
52
LAN Switch
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2,5
Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
53 53
Module2.ppt
53
LAN Switch
CPU
Switching Engine
6Mbps MPEG Video
CAM Table
2
MAC Address 0100.5e01.0203 Ports 0,1,2,5
Host 3
Host 4
8/9/2001 4:20 PM
54 54
Summary
IGMP Snooping can be (and often is) implemented in low-end, Layer-2 only switches using techniques similar to the above. While this is fine for extremely low data-rate multicast flows or carefully orchestrated vendor demonstrations of their switchs IGMP Snooping feature, it is generally inadequate for real-world use.
Module2.ppt
54
L3 Aware Switch
Router A 1 (IGMP Snooping Enabled) 0
LAN Switch
CPU
CAM Table
2
MAC Address 0100.5exx.xxxx L3 IGMP Ports 0
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
55 55
Module2.ppt
55
LAN Switch
CPU
CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 L3 IGMP !IGMP Ports 0 1,2
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
56 56
Module2.ppt
56
LAN Switch
CPU
CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
L3 IGMP !IGMP
Ports 0 1,2,5
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
57 57
Module2.ppt
57
L3 Aware Switch
Ahhh, Thats more like it!
Router A
LAN Switch
CPU
CAM Table
2
MAC Address 0100.5exx.xxxx 0100.5e01.0203 L3 IGMP !IGMP Ports 0 1,2,5
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
58 58
Summary
In order to construct a switch that is capable of IGMP Snooping without suffering a performance hit, the switch must use special Layer 3 ASIC or some similar technique. This increases the overall cost of the switch.
Module2.ppt
58
CGMP Commands
IGMP
Switch uses CGMP packet info to add or remove an entry for a particular multicast MAC address
Module2. ppt
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.
Module2.ppt
59
CGMP Basics
IGMP Report
Dst MAC = 0100.5e01.0203 Src MAC = 0080.c7a2.1093 Dst IP = 224.1.2.3 Src IP = 192.1.1.1 IGMP Group = 224.1.2.3
CGMP Join
1/1 1/1
USA = 0080.c7a2.1093 GDA = 0100.5e01.0203
5/1
5/1
(a)
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
(b)
8/9/2001 4:20 PM
60 60
CGMP Example
In this example - the client will asynchronously send an IGMP Membership Report when it wants to join the group. The Router converts this IGMP Membership Report into a CGMP Join containing: USA - Unicast Source Address GDA - Group Destination Address The CGMP Join is multicast to a well-known (non-IP) multicast MAC address which the switch listens on.
Module2.ppt
60
Ver (4 bits): Type (4 bits): Count (1 byte): GDA (6 bytes): USA (6 bytes):
Only version 1 is currently recognized and supported 0 = Join, 1 = Leave Number of GDA/USA pairs in the packet Group Destination Address - IEEE MAC level canonical format Unicast Source Address - IEEE MAC-level canonical format
Module2. ppt
8/9/2001 4:20 PM
61 61
Most sniffers and software capture programs do not decode CGMP (have fun with the hex decodes)
Module2.ppt
61
CPU
Switching Engine
CAM Table
2
MAC Address Ports
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7a2.1093
62 62
Module2.ppt
62
CPU
Switching Engine
CGMP Join USA 0080.c7a2.1093 GDA 0100.5e01.0204
CAM Table
2
MAC Address Ports
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7a2.1093
63 63
Module2.ppt
63
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2
Entry Added
Module2. ppt
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7a2.1093
64 64
Module2.ppt
64
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7b3.2174
65 65
Module2.ppt
65
CPU
Switching Engine
CGMP Join USA 0080.c7b3.2174 GDA 0100.5e01.0204
CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2
Host 1
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7b3.2174
66 66
Module2.ppt
66
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2,5
Port Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 1
Host 2
Host 3
Host 4
8/9/2001 4:20 PM
0080.c7b3.2174
67 67
Module2.ppt
67
CPU
Switching Engine
6Mbps MPEG Video
CAM Table
2
MAC Address 0100.5e01.0203 Ports 1,2,5
Host 3
Host 4
8/9/2001 4:20 PM
68 68
Module2.ppt
68
CGMP Messages
GDA
Mcst MAC Mcst MAC 00000000 00000000 Mcst MAC 00000000
USA
Client MAC Client MAC Router MAC Router MAC 00000000 00000000
Join/Leave Meaning
Join Leave Join Leave Leave Leave Add USAs port to the Group Delete USAs port from Group Assign Port = Router Port Deassign Port = Router Port Delete Group from CAM Delete ALL Groups from CAM
Module2. ppt
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)
Module2.ppt
69
Notes
Enable CGMP per (Sub) Interface Enables CGMP and DVMRP Proxy per (Sub) Interface Debugs CGMP Activity Shows if CGMP Is Enabled or Disabled Clears All CGMP Groups
debug ip cgmp show ip igmp interface [int [int] ] clear ip cgmp [int int] ]
Module2. ppt
8/9/2001 4:20 PM
70 70
Module2.ppt
70
Command
set cgmp enable|disable show multicast router show multicast group show cgmp statistics clear cgmp statistics
Notes
Globally Enable or Disable cgmp Displays Which Ports Are Router Ports Shows which Groups Are Active Shows CGMP Statistics Clears CGMP Statistics
8/9/2001 4:20 PM
71 71
Module2.ppt
71
Command
set multi router <mod/port> clear multicast router <mod/port> set cgmp leave <en|dis <en|dis> >
Notes
Designates port a router port Deletes multicast router port information Enables/disables fast leave processing
8/9/2001 4:20 PM
72 72
Module2.ppt
72
SummaryFrame Switches
IGMP snooping
Switches with Layer 3 aware ASICs
High-throughput performance maintained Increases cost of switches
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.
Module2.ppt
73
Video Server
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
74 74
Example:
In the above drawing, the Video Server is located on one of the ports of the 2900 closet switches. This server is sourcing high-rate video for which there are no receivers in the LAN switching environment. However, the IP Multicast host model defined in RFC 1112 requires that this traffic flow must at all times be sent to the router. This results in traffic flowing over the inter-switch trunk that may not be necessary. Certainly, if there are no receivers beyond the router, this traffic flow is just wasting trunk bandwidth.
Module2.ppt
74
Catalyst 5000
VLAN1 VLAN2 VLAN3
Catalyst 29xx
Catalyst 29xx
Catalyst 29xx
8/9/2001 4:20 PM
75 75
Module2.ppt
75
Router A
7500
1.5MB MPEG Video Streams
T1
Catalyst 5000
2500 2500
WAN
Router D
Router B
7500
7500
Receiver Group 2
Router C
Receiver Group 1
Module2. ppt
8/9/2001 4:20 PM
76 76
Example:
Consider the network shown in the drawing above. Three campus routers are connected via 100Mbps Ethernet to a core switch. A video server connected to Router A is sourcing two 1.5Mbps MPEG video multicast streams, one to Group 1 and another to Group 2. Router B has a directly connected member of Group 1 and therefore needs the 1.5Mbps Group 1 video stream. Router C has a directly connected member of Group 2 and therefore needs the 1.5Mbps Group 1 video stream. Because both Routers B & C are on the same Ethernet segment (albeit on different ports on the switch), they each receive both Group 1 & 2 video streams even though they only need one. Even worse, Router D has been connected to this core backbone Ethernet segment for the purpose of supplying remote sites with unicast connectivity and low rate multicast. (i.e. there is no intention of sending MPEG video to the remote sites.) Unfortunately, the little 2500 will also receive both of the high-rate video streams for a total of 3Mbps of unwanted traffic! While the 2500 is capable of fast-dropping the unwanted traffic in the fastswitching path, it still has a significant impact on the performance of the router.
Module2.ppt
76
Router A
7500
1.5MB MPEG Video Streams
2500 2500
T1
WAN
Router-D
Catalyst 5000
Router B
7500
7500
Receiver Group 2
Router C
Receiver Group 1
Module2. ppt
8/9/2001 4:20 PM
77 77
Solution
By connecting Router D to a separate LAN segment off of Router A (this could be accomplished using another port on Router A and a separate VLAN in the Cat5000), Router D is able to prune off any unwanted traffic. Exercise 1: Why is this now possible? (See answer below.) Unfortunately, we still have unwanted traffic flowing to Routers B & C. One might argue that the same solution used for Router D could be used which is true. However, this would require additional Ethernet ports on Router A. The other solution would be to use multiple VLANs on the single Ethernet port on Router A. Unfortunately, this would significantly reduce the overall bandwidth available and is a sub-optimal solution.
Answer to Exercise 1: Because there is no other router on the LA N segment, Router A is able to Prune off the traffic flow without the Prune being overridden by another router on the LAN segment.
Module2.ppt
77
Solution: (RGMP)
Router Group Management Protocol
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
78 78
Module2.ppt
78
Switches
Do not forward multicast traffic to router ports until specifically requested.
Limitations:
Only works with PIM-SM/PIM-SSM No Hosts permitted on VLAN
Routers cannot detect sources since multicast flooding to routers is off by default.
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
79 79
Module2.ppt
79
RGMP
Initially, multicast forwarding to routers is disabled
RGMP Switch
CPU
Switching Engine
CAM Table
1
MAC Address 0100.5exx.xxxx Ports
2 B C
3 D
Module2. ppt
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.
Module2.ppt
80
RGMP
1st Router receives a PIM (*,G) Join from downstream
RGMP Switch
CPU
Switching Engine
RGMP Join
0100.5e01.0101
CAM Table
1
MAC Address 0100.5exx.xxxx 0100.5e01.0101 0100.5exx.xxxx Ports 2
2 B C
3 D
Entry Added
Module2. ppt
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.
Module2.ppt
81
RGMP
2nd Router receives a PIM (*,G) Join from downstream
RGMP Switch
CPU
Switching Engine
RGMP Join
0100.5e01.0101
CAM Table
1
MAC Address 0100.5e01.0101 0100.5exx.xxxx Port Added Ports 2,4
2 B C
3 D
Module2. ppt
8/9/2001 4:20 PM
82 82
RGMP Example:
When router D receives a downstream PIM (*,G) Join for group 224.1.1.1, it too sends an RGMP Join for the corresponding MAC address, 0x0100.5e01.0101. When the switch receives the RGMP Join message from router D, it updates the entry in its CAM table for 0x0100.5e01.0101 by adding the port number associated with router D.
Module2.ppt
82
RGMP
Multicast is constrained to routers B and D
RGMP Switch
CPU
Switching Engine
CAM Table
1
MAC Address 0100.5e01.0101 0100.5exx.xxxx Ports 2,4
2 B C
3 D
Source
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
83 83
RGMP Example:
When a source behind router B begins transmitting to group 224.1.1.1, router B forwards this traffic to the core router backbone (the switch). The CAM table entry in the switch now effectively constrains the multicast traffic to routers B and D. Routers A and C, which have not joined the multicast group, do not receive the traffic.
Module2.ppt
83
CPU
Switching Engine
CAM Table
2
MAC Address Ports
Host 1
Router B
Router C
Router D
8/9/2001 4:20 PM
Module2. ppt
84 84
Example:
Consider the OSPF LAN segment running through the above switch that has four OSPF routers plus one host. Because there is no entry in the CAM Table for the MAC address equivalent of 224.0.0.5 (OSPF Router Hello), the OSPF Hello messages are being flooded to all OSPF routers on the segment and OSPF adjacency is being maintained.
Module2.ppt
84
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e00.0005 Ports 2
Entry Added
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Host 1
Router B
Router C
Router D
8/9/2001 4:20 PM
85 85
Module2.ppt
85
CPU
Switching Engine
CAM Table
2
MAC Address 0100.5e00.0005 Ports 2
Host 1
Router B
Router C
Router D
8/9/2001 4:20 PM
Module2. ppt
86 86
Note:
This is a hotly debated issue in the IETF that stems from the fact that the IGMPv2 spec states that with the exception of 224.0.0.2, all devices MUST join the multicast group in order to receive traffic from the group. Unfortunately, this implies that all router vendors must rewrite their existing routing protocols (such as OSPF) so that the router sends IGMP Membership Reports for such groups as All OSPF Routers, 224.0.0.5, All OSPF DRs, 224.0.0.6, All EIGRP Routers, 224.0.0.10, etc., etc. This is clearly an absurd idea as even if all vendors did rewrite their implementations to be compliant with the new IGMP spec, it would mean that the customer would have to wholesale upgrade all routers in the network in a flag day. This might even require changing out router hardware in order to be able to run the latest code. For this reason, Cisco has chosen to address this problem by having all switches flood any IP multicast traffic with a destination MAC address falling in the range of 0x0100.5e00.00xx. This guarantees that protocols that use linklocal multicast will continue to function properly.
Module2.ppt
86
0x0100.5E00.00xx
8/9/2001 4:20 PM
87 87
Module2.ppt
87
0x0100.5E01.0101
Module2. ppt
8/9/2001 4:20 PM
88 88
Module2.ppt
88
SummaryDesign Issues
Pay attention to campus topology
Be aware of unwanted flooding over trunks
224.0.0.x flooding
Watch out for switches that dont flood 224.0.0.x traffic
Address overlap
Select group addresses to avoid L2 overlap Avoid x.0.0.x group addresses when possible
Module2. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/9/2001 4:20 PM
89 89
Module2.ppt
89
BUS
Unwanted Data!!!
Source Member
8/9/2001 4:20 PM
Module2. ppt
90 90
Module2.ppt
90
BUS
Make Sure Your ATM Switches Can Replicate Cells at this Rate!
Member
Module2. ppt
8/9/2001 4:20 PM
91 91
Module2.ppt
91
BUS
ELAN 3
Module2. ppt
8/9/2001 4:20 PM
92 92
Module2.ppt
92
8/9/2001 4:20 PM
93 93
Module2.ppt
93
Module2. ppt
94
Module2.ppt
94
Module3. ppt
8/10/2001 11:41 AM
Module3.ppt
Module Objectives
Identify and explain the basic mechanisms of PIM Dense Mode. Identify the packet types used by PIM Dense Mode. Configure and verify normal PIM DM operation.
Module3. ppt
8/10/2001 11:41 AM
2 2
Module3.ppt
Module Agenda
Geekometer
PIM Dense Mode Overview PIM Packet Formats PIM Dense Mode Concepts PIM Dense Mode Review Configuring PIM Dense-Mode
Module3. ppt
8/10/2001 11:41 AM
3 3
Module3.ppt
Multicast forwarding state is created by the arrival of data If the source goes inactive, the tree is torn down
Module3. ppt
8/10/2001 11:41 AM
4 4
Module3.ppt
Grafts are used to join existing source tree Asserts are used to determine forwarder for multi-access LAN Prunes are sent on non-RPF P2P links
Asserts are sent on non-RPF multi-access links
Module3. ppt
8/10/2001 11:41 AM
5 5
Initial Flooding
Source
Multicast Packets
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.
Module3.ppt
Source
8/10/2001 11:41 AM
7 7
Module3.ppt
Source
Multicast Packets
Receiver
8/10/2001 11:41 AM
8 8
Module3.ppt
PIM Packet Headers PIM Hello Messages PIM Join/Prunes PIM Grafts/Graft Acks PIM Asserts
Module3. ppt
8/10/2001 11:41 AM
9 9
Module3.ppt
Module3. ppt
8/10/2001 11:41 AM
10 10
Module3.ppt
10
Code: 0 = Router-Query 1 = Register (SM only) 2 = Register-Stop (SM only) 3 = Join/Prune 4 = RP-Reachibility (SM only) 5 = Assert 6 = Graft 7 = Graft-ACK Ver: PIM Version = 1
PIMv1 messages are multicast to the ALL-Routers (224.0.0.2) group with a TTL of 1.
Note: (PIMv1 packet formats are not shown. Only PIMv2 packets wi ll be given.)
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
11 11
Module3.ppt
11
Ver: PIM Version = 2 Type: 0 = Hello 1 = Register 2 = Register-Stop 3 = Join/Prune 4 = Bootstrap 5 = Assert 6 = Graft 7 = Graft-Ack 8 = C-RP-Announcement
(SM only) (SM only) (SM BSR only) (DM only) (DM only) (SM BSR only)
PIMv2 messages are multicast to the ALL-PIM-Routers (224.0.0.13) group with a TTL of 1.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
12 12
Module3.ppt
12
Option Type
Option Types: 1 = Holdtime (Period of time in seconds before this PIM neighbor times out.) 19 = DR Priority 20 = Generation ID
13 13
Module3. ppt
8/10/2001 11:41 AM
Module3.ppt
13
Group List
Module3. ppt
8/10/2001 11:41 AM
14 14
Module3.ppt
14
Join Source-1 (Encoded-Source) Join Source-n (Encoded-Source) Prune Source-1 (Encoded-Source) Prune Source-n (Encoded-Source) Group-2 (Encoded-Group) Number of Join Sources Number of Prune Sources
8/10/2001 11:41 AM
15 15
Group Lists
Group Lists are used in Join/Prune messages as well as Graft and Graft -Ack messages. A Group List is a list of Group entries each beginning with a Group IP Address and Group mask to identify the Multicast Group. Each Group List entry contains a list of zero or more sources to Join followed by a list of zero or more sources to Prune. Group IP Address Number of Join Sources Number of Prune Sources Join List Prune List The addresses used in Join and Prune lists use a special encoded format that allows for other protocols besides IPv4. (See next slides.)
Module3.ppt
15
Module3. ppt
8/10/2001 11:41 AM
16 16
Module3.ppt
16
23 SWR
31 Mask Len
8/10/2001 11:41 AM
17 17
Module3.ppt
17
Module3. ppt
8/10/2001 11:41 AM
18 18
Module3.ppt
18
Module3. ppt
8/10/2001 11:41 AM
19 19
Module3.ppt
19
8/10/2001 11:41 AM
20 20
Module3.ppt
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
Module3.ppt
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
8/10/2001 11:41 AM
22 22
Module3.ppt
22
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Forwarding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
23 23
Module3.ppt
23
PIM Query PIM-DM Router 1 171.68.37.1 PIM Queries are Multicast to the All-Routers (224.0.0.2) (with a TTL of 1) multicast group address periodically. (Default = 30 seconds ) If the DR times-out, a new DR is elected. In PIM DM, interface is added to outgoing interface list for all groups when first neighbor is heard.
Module3. ppt
8/10/2001 11:41 AM
24 24
Module3.ppt
24
Uptime Uptime 2w1d 2w1d 2w6d 2w6d 7w0d 7w0d 7w0d 7w0d 7w0d 7w0d 22:47:11 22:47:11 22:47:22 22:47:22 22:47:07 22:47:07 1d04h 1d04h 1w4d 1w4d 1d04h 1d04h 12:53:25 12:53:25
Expires Expires 00:01:24 00:01:24 00:01:01 00:01:01 00:01:14 00:01:14 00:01:13 00:01:13 00:01:02 00:01:02 00:01:16 00:01:16 00:01:08 00:01:08 00:01:21 00:01:21 00:01:06 00:01:06 00:01:25 00:01:25 00:01:20 00:01:20 00:01:03 00:01:03
Mode Mode Dense Dense Dense Dense (DR) (DR) Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense Dense
Module3. ppt
8/10/2001 11:41 AM
25 25
Module3.ppt
25
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
26 26
Module3.ppt
26
PIM State
Describes the state of the multicast distribution trees as understood by the router at this point in the network. Represented by entries in the multicast routing (mroute) table Used to make multicast traffic forwarding decisions Composed of (*, G) and (S, G) entries Each entry contains RPF information
Incoming (i.e. RPF) interface RPF Neighbor (upstream)
Module3. ppt
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.
Module3.ppt
27
Module3. ppt
8/10/2001 11:41 AM
28 28
Module3.ppt
28
8/10/2001 11:41 AM
29 29
Module3.ppt
29
8/10/2001 11:41 AM
30 30
Module3.ppt
30
J = Join SPT
Always on in (*,G) entry in PIM-DM Basically meaningless in PIM-DM
Module3. ppt
8/10/2001 11:41 AM
31 31
Module3.ppt
31
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
32 32
Module3.ppt
32
PIM DM Flooding
S0 S3 S1
rtr-a
S0
rtr-b
E1
PIM Dense mode interfaces are placed on the (*,G) oilist for a Multicast Group IF:
PIM neighbor heard on interface Host on this interface has joined the group Interface has been manually configured to join group.
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.
Module3.ppt
33
PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
34 34
Arriving data causes rtr-a to create state A parent (*, G) entry must first be created before the (S, G) entry can be created.
The (*, 224.2.127.254) entry is created and the outgoing interface list is populated with interfaces that: Have a PIM -DM neighbor or Have a directly connected member or Has manually be configured to join the group (Note: In this example, PIM-DM neighbors are assumed to be connected to rtr-a via S0 and S1.)
34
PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
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.
Module3.ppt
35
PIM DM Flooding
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: PT PT Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.2.31 198.92.2.31 Outgoing Outgoing interface interface list: list: Null Null
Module3. ppt
8/10/2001 11:41 AM
36 36
Arriving data causes rtr-b to create state A parent (*, G) entry must first be created before the (S, G) entry can be created.
The (*, 224.2.127.254) entry is created and the outgoing interface list is populated with interfaces that: Have a PIM -DM neighbor or Have a directly connected member or Has manually be configured to join the group This results in only Serial0 being places in the (*,G) oil.
Module3.ppt
36
Source
Interface previously Pruned by Assert Process
RPF Interface
Module3. ppt
8/10/2001 11:41 AM
37 37
Module3.ppt
37
RPF Interface
Module3. ppt
8/10/2001 11:41 AM
38 38
Module3.ppt
38
Module3. ppt
8/10/2001 11:41 AM
39 39
Module3.ppt
39
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
40 40
Module3.ppt
40
PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:59, 00:00:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial1, Forward/Dense, Serial1, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 Serial3, Forward/Dense, 00:00:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:10/00:02:49, 00:00:10/00:02:49, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:10/00:00:00 00:00:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
41 41
Module3.ppt
41
PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) 2 Prune S0 S3 S1
rtr-a
E1
1 2 3
rtr-a initially floods (S, G) traffic out all interfaces in oilist. rtr-b is a leaf node w/o receivers. Sends Prune for (S,G). rtr-a Prunes interface for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.
rtr-b
Module3. ppt
8/10/2001 11:41 AM
42 42
Step 1
As a result of the initial flooding state (shown in the previous slide), rtr-a is flooding (S, G) traffic out interfaces Serial3 and Serial 1.
Step 2
rtr-b is a leaf node without any downstream PIM-DM neighbors or directly connected members of the group. This is reflected in rtr-bs (S, G) entry (shown in the previous slide) by the Null OIL and the corresponding P flag being set. As a result of the above, rtr-b sends an (S, G) Prune message to rtr-a to shutoff the flow of unwanted traffic.
Step 3
rtr-a responds by pruning interface Serial3. (This is reflected in the (S, G) state shown in the next slide.)
Module3.ppt
42
PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial3, Serial3, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing interface list: Outgoing interface list: Serial1, Serial1, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 Serial3, Serial3, Prune/Dense, Prune/Dense, 00:00:12/00:02:56 00:00:12/00:02:56
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
43 43
Module3.ppt
43
PIM DM Pruning
S0 Multicast Packets (128.9.160.43, 224.2.127.254) S3 S1
rtr-a
S0
rtr-b
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:59, 00:00:12/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:00:12/00:00:00 00:00:12/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:00:12/00:02:48, 00:00:12/00:02:48, flags: flags: PT PT Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.2.31 198.92.2.31 Outgoing Outgoing interface interface list: list: Null Null
Module3. ppt
8/10/2001 11:41 AM
44 44
Module3.ppt
44
Prune
E0
Join 3
rtr-b
E1
rtr-c
E1
Receiver
1 2 3 4
rtr-b is a leaf node w/o receivers. Sends Prune for (S,G). rtr-a schedules a Prune for (S,G) to occur in 3 seconds. rtr-c hears Prune from rtr-b. Overrides with a Join. rtr-a hears Join and cancels Prune for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.
Module3. ppt
8/10/2001 11:41 AM
45 45
Module3.ppt
45
X X
Prune 3 sec delay 3 sec delay Prune
X X
Prune 3 sec delay 3 sec delay Prune
Source begins sending traffic which is flooded everywhere. Leaf router has no receivers; sends prune which ripples up the tree. Total time to prune back to source = 12 seconds! Process repeats 3 minutes later when prunes timeout!
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
46 46
Module3.ppt
46
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
47 47
Module3.ppt
47
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
Beginning State
rtr-b and rtr-c have previously Pruned (S,G) traffic. rtr-a is still forwarding traffic downstream via S1.
Module3. ppt
8/10/2001 11:41 AM
48 48
Module3.ppt
48
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing Outgoing interface interface list: list: Ethernet0, Ethernet0, Prune/Dense, Prune/Dense, 00:01:29/00:01:30 00:01:29/00:01:30 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
49 49
Module3.ppt
49
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null
8/10/2001 11:41 AM
50 50
Module3.ppt
50
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null
8/10/2001 11:41 AM
51 51
Module3.ppt
51
PIM DM Grafting
S0 (S,G) Packets 3 PIM Graft-ACK E0 2 PIM Graft E1
IGMP Join Rcvr A
S1 E0
rtr-a
4 E0
rtr-b
rtr-c
E1 1
1 2 3 4
Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends PIM Graft for Group (S,G). rtr-a acknowledges with a PIM Graft-Ack. rtr-a begins forwarding traffic for (S,G).
1998 2001, Cisco Systems, Inc. All rights reserved.
Module3. ppt
8/10/2001 11:41 AM
52 52
Module3.ppt
52
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 198.92.1.129 198.92.1.129 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:00:25/00:00:00 00:00:25/00:00:00 Serial1, Serial1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
53 53
Module3.ppt
53
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:00:00, 00:04:10/00:00:00, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 Ethernet1, Ethernet1, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: C CT T Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Outgoing interface list: Ethernet1, Ethernet1, Forward/Dense, Forward/Dense, 00:00:26/00:00:00 00:00:26/00:00:00
8/10/2001 11:41 AM
54 54
Module3.ppt
54
PIM DM Grafting
S0 (S,G) Packets S1 E0
rtr-a
E0
E0
rtr-b
E1
rtr-c
E1
(*, (*, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:59, 00:04:10/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: D D Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Outgoing interface list: Ethernet0, Ethernet0, Forward/Dense, Forward/Dense, 00:04:10/00:00:00 00:04:10/00:00:00 (128.9.160.43/32, (128.9.160.43/32, 224.2.127.254), 224.2.127.254), 00:04:10/00:02:39, 00:04:10/00:02:39, flags: flags: PT PT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 198.92.2.1 198.92.2.1 Outgoing interface list: Null Outgoing interface list: Null
8/10/2001 11:41 AM
55 55
Module3.ppt
55
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
56 56
Module3.ppt
56
S0 A E0 .1 192.168.1.0/24 1
S0 B E0 .2
C 1
Receiver
Module3. ppt
8/10/2001 11:41 AM
57 57
Step 1
Routers A & B receive both receive the same (S, G) traffic via their proper RPF interfaces (Serial0) and forward the packet onto the common Ethernet segment. Routers A & B therefore will receive an (S, G) packet via a multi-access interface that is in the Outgoing Interface list of their (S, G) entry. This triggers the Assert mechanism.
Module3.ppt
57
Winner B E0 .2
X
C
Receiver
Module3. ppt
8/10/2001 11:41 AM
58 58
Step 2
Routers A & B both send PIM Assert messages that contain their Administrative Distance and route Metric back to the source. Note: The Administrative Distance and route Metric is treated as a single combined numeric value where the Administrative Distance is the high-order part of the numeric value. Therefore, even though different routing protocols use different metrics, the lower Administrative Distance will take precedence. Each router compares the received Administrative Distance/Metric value with its own and the router with the best (lowest) value wins the Assert. In case of a tie, the highest IP address is used as the tie breaker. The losing router will Prune its interface just as if it had received a Prune on this interface. Note: This prune will timeout in 3 minutes and cause the router to begin forwarding on this interface again. This triggers another Assert process. By the same token, if the winning router were to crash, the loser would take over the job of forwarding onto this LAN segment after its prune timed out.
Module3.ppt
58
If there are no directly connected members on the interface, the winning router sends a Prune and waits 3 seconds for a Join override. This will shutoff traffic if it is not needed somewhere downstream. Router C does need traffic. Sends join to override.
1998 2001, Cisco Systems, Inc. All rights reserved.
X
C
Receiver
4
Module3. ppt
8/10/2001 11:41 AM
59 59
Step 3
In the case where there are no directly connected members on the LAN segment (as is the case in our example), the winning router will send an (S,G) Prune message and schedule its interface to be pruned after the normal 3 second prune delay. This mechanism allows traffic to be shutoff if there are no members of the group further downstream of the LAN segment. (Which is not the case in the figure above.
Step 4
In this example, downstream router C does need the traffic (it has a directly connected receiver) so it responds to the (S, G) Prune sent by the winning router by sending an overriding (S, G) Join. This cancels the scheduled Prune in Router B and thereby continues the flow of (S, G) traffic onto the transit LAN.
Module3.ppt
59
5 6
If router C doesnt need the traffic, no Join override is sent. Router B prunes its interface after 3 second prune delay.
This stops the flow of traffic onto the transit LAN.
1998 2001, Cisco Systems, Inc. All rights reserved.
X
C
X
60 60
Module3. ppt
8/10/2001 11:41 AM
Step 5
On the other hand, if the none of the downstream router(s) need the traffic (as is the case in the example shown above), no (S, G) Join is sent to override the (S, G) Prune sent by the winning router, Router B.
Step 6
After the normal 3 second Prune delay expires and Router B has not received an (S, G) Join to override the prune, it goes ahead and Prunes its interface. This shuts off the flow of traffic onto the transit LAN segment. Note: The prune of Router Bs Ethernet interface will timeout after 3 minutes just as if it had received an (S, G) prune on this interface. This means that traffic will start to flow via this interface after 3 minutes which will trigger Router A to start the Assert process all over again.
Module3.ppt
60
B
E0 .2
198.92.2.0/24
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null
Module3. ppt
8/10/2001 11:41 AM
61 61
Module3.ppt
61
A
E0
S0
S0
B
E0 .2
Assert Loser
Assert
198.92.2.0/24
C
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null
Module3. ppt
8/10/2001 11:41 AM
62 62
Module3.ppt
62
A
E0
S0
S0
B
E0 .2
Assert Loser
Pruned
X
198.92.2.0/24
C
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.2 Outgoing interface list: Null
Module3. ppt
8/10/2001 11:41 AM
63 63
Module3.ppt
63
A
E0
S0
S0
B
E0 .2
Assert Loser
198.92.2.0/24
Assert Winner
(128.9.160.43/32, 224.2.127.254), 00:04:10/00:02:39, flags:PT Incoming interface: Ethernet0, RPF nbr 198.92.2.1 Outgoing interface list: Null
Module3. ppt
8/10/2001 11:41 AM
64 64
Module3.ppt
64
Initial Flow
Duplicate Traffic
Receiver
Receiver
Multicast Packets
Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
65 65
Module3.ppt
65
Sending Asserts
Loser
Receiver
Receiver
Winner
8/10/2001 11:41 AM
66 66
Module3.ppt
66
Receiver
Receiver
Winner
Multicast Packets
Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
67 67
Module3.ppt
67
Receiver
Receiver
X
Winner Multicast Packets Source
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
68 68
Module3.ppt
68
PIM DM Concepts
PIM Neighbor Discovery PIM DM State PIM DM Flooding PIM DM Pruning PIM DM Grafting PIM Assert Mechanism PIM DM State Maintenance
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
69 69
Module3.ppt
69
Interface prune state times out every 3 minutes causing periodic reflooding and pruning.
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 11:41 AM
70 70
Module3.ppt
70
Module3. ppt
8/10/2001 11:41 AM
71 71
Module3.ppt
71
Module3. ppt
8/10/2001 11:41 AM
72 72
Module3.ppt
72
A Prune C
B G D F H E I Receiver 2
Receiver 1
Module3. ppt
8/10/2001 11:41 AM
73 73
Module3.ppt
73
Module3. ppt
8/10/2001 11:41 AM
74 74
Module3.ppt
74
B G
D Prune E I
F H
Receiver 1
Receiver 2
Module3. ppt
8/10/2001 11:41 AM
75 75
Module3.ppt
75
B G
C Prune E Receiver 1
F H I Receiver 2
Module3. ppt
8/10/2001 11:41 AM
76 76
Module3.ppt
76
Module3. ppt
8/10/2001 11:41 AM
77 77
Module3.ppt
77
B G
D Graft E I
F H
Receiver 1 Receiver 3
Module3. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Receiver 2
8/10/2001 11:41 AM
78 78
Module3.ppt
78
B G
F H
E Receiver 1
I Receiver 2 Receiver 3
Module3. ppt
8/10/2001 11:41 AM
79 79
Module3.ppt
79
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
Module3.ppt
80
Module2. ppt
81
Module3.ppt
81
Module4. ppt
8/10/2001 1:55 PM
Module4.ppt
Module Objectives
Introduction to IOS Command Line Interface (CLI) tools Understand usage and key information fields for IOS CLI tools in troubleshooting and monitoring the router and network Develop a Strategy for debugging multicast networks
Module4. ppt
8/10/2001 1:55 PM
Module4.ppt
Module Agenda
Module4. ppt
8/10/2001 1:55 PM
Module4.ppt
Module4. ppt
8/10/2001 1:55 PM
Module4.ppt
R4#show R4#show ip ip igmp igmp group group IGMP IGMP Connected Connected Group Group Membership Membership Group Address Interface Group Address Interface 224.1.1.1 Ethernet1 224.1.1.1 Ethernet1 224.0.1.40 Ethernet0 224.0.1.40 Ethernet0
Expires eporter Expires Last Last RR eporter 00:01:59 .7.2 00:01:59 172.16 172.16 .7.2 never 172.16 .6.2 never 172.16 .6.2
Module4. ppt
8/10/2001 1:55 PM
Uptime - shows how long there has been membership for the listed group on that interface Expires - shows when membership interest will end - IGMP reports from client members of this group are what keep this timer from expiring - you should see this value reset and not timeout as long as there are members present. When this timer expires - the multicast routing protocol is notified to stop delivery of that group onto this interface Only the last IGMP reporter is listed - this is due to report suppression
Module4.ppt
Module4. ppt
8/10/2001 1:55 PM
This is the command to verify IGMP and CGMP are enabled or disabled on the interface IGMP version can be verified with this command - this is important if you have a mixed environment of multicast routing protocols running or other routers that support different versions of IGMP - some IGMP configuration may be required IGMP timers can be verified here for tuning purposes The multicast designated router (DR) and IGMP querier for this link can also be determined with this command
Module4.ppt
R6#show R6#show ip ip pim pim neighbor neighbor PIM PIM Neighbor Neighbor Table Table Neighbor Address Neighbor Address Interface Interface 172.16.10.2 Serial0 172.16.10.2 Serial0 172.16.11.2 Serial1 172.16.11.2 Serial1 172.16.9.1 Ethernet0 172.16.9.1 Ethernet0
Module4. ppt
8/10/2001 1:55 PM
Uptime - indicates how long the neighbor adjacency has existed Expires - indicates when the adjacency will timeout and be removed PIM hellos maintain this adjacency Mode - indicates what mode the interface is running in
Module4.ppt
R6#show R6#show ip ip pim pim interface interface Address Interface Address Interface 172.16.10.1 172.16.10.1 172.16.11.1 172.16.11.1 172.16.9.2 172.16.9.2 Serial0 Serial0 Serial1 Serial1 Ethernet0 Ethernet0
Nbr DR Nbr Query Query DR Count Count Intvl Intvl 11 30 0. 0.0.0 30 0. 0.0.0 11 30 0. 0.0.0 30 0. 0.0.0 11 30 17 2.16.9.2 30 17 2.16.9.2
Module4. ppt
8/10/2001 1:55 PM
Nbr Count = number of neighbors on this link DR = 0.0.0.0 in this example because p2p links do not have DRs
Module4.ppt
show ip rpf
R4#show R4#show ip ip rpf rpf 172.16.8.1 172.16.8.1 RPF RPF information information for for R1 R1 (172.16.8.1) (172.16.8.1) RPF RPF interface: interface: Ethernet0 Ethernet0 RPF RPF neighbor: neighbor: R3 R3 (172.16.6.1) (172.16.6.1) RPF RPF route/mask: route/mask: 172.16.8.0/255.255.255.0 172.16.8.0/255.255.255.0 RPF type: unicast RPF type: unicast R4#sh R4#sh ip ip rpf rpf 172.16.12.2 172.16.12.2 RPF RPF information information for for Source1 Source1 (172.16.12.2) (172.16.12.2) RPF interface: RPF interface: Ethernet0 Ethernet0 RPF neighbor: R6 (172.16.11.1) RPF neighbor: R6 (172.16.11.1) RPF RPF route/mask: route/mask: 172.16.12.0/255.255.255.0 172.16.12.0/255.255.255.0 RPF RPF type: type: unicast unicast
Module4. ppt
8/10/2001 1:55 PM
Top example is obtaining RPF information for the RP (on R1) The RPF interface is the interface used to reach the target address (The RP itself in this example) Also shown is the RPF neighbor on the RPF interface and the route and mask used to reach the target address The second example is the RPF information for the source of the multicast group
Module4.ppt
show ip route
R4#show R4#show ip ip route route Gateway Gateway of of last last resort resort is is not not set set DD DD DD DD CC DD DD DD 172.16.0.0/24 ,, 77 subnets 172.16.0.0/24 is is subnetted subnetted subnets 172.16.2.0 172.16.2.0 [90/2354611] [90/2354611] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.3.0 [90/2354611] via 172.16.3.0 [90/2354611] via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.4.0 172.16.4.0 [90/2221056] [90/2221056] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.5.0 172.16.5.0 [90/2221056] [90/2221056] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.6.0 172.16.6.0 [90/2281542] [90/2281542] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet0 Ethernet0 172.16.10.0 00 172.16.10.0 [90/2281542] [90/2281542] via via 172.16.6.1, 172.16.6.1, 4d15h, 4d15h, Ethernet Ethernet 172.16.8.0 [90/2221056] via 172.16.6.1, 4d15h, Ethernet0 172.16.8.0 [90/2221056] via 172.16.6.1, 4d15h, Ethernet0 192.169.1.0/24 192.169.1.0/24 is is subnetted, subnetted, 11 subnets subnets 192.169.1.0 00 192.169.1.0 [90/2349056] [90/2349056] via via 172.16.6.1, 172.16.6.1, 3d15h, 3d15h, Ethernet Ethernet
Module4. ppt
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
Module4.ppt
10
R6#show R6#show ip ip mroute mroute summary summary IP IP Multicast Multicast Routing Routing Table Table Flags: Flags: DD -- Dense, Dense, SS -- Sparse, Sparse, CC -- Connected, Connected, LL -- Local, Local, PP -- Pruned Pruned RR -- RP-bit RP-bit set, set, FF -- Register Register flag, flag, TT -- SPT-bit SPT-bit set, set, JJ -- Join Join SPT SPT Timers: Timers: Uptime/Expires Uptime/Expires Interface Interface state: state: Interface, Interface, Next-Hop, Next-Hop, State/Mode State/Mode (*, (*, 224.1.1.1), 224.1.1.1), 00:01:47/00:02:55, 00:01:47/00:02:55, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DD (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), 00:01:47/00:02:54, 00:01:47/00:02:54, flags: flags: CT CT (*, (*, 224.0.1.40), 224.0.1.40), 3d16h/00:00:00, 3d16h/00:00:00, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DCL DCL
Module4. ppt
8/10/2001 1:55 PM
11 11
Module4.ppt
11
show ip mroute
barrnet -gw>show barrnet -gw>show ip ip mroute mroute IP IP Multicast Multicast Routing Routing Table Table Flags: D Dense, S Flags: D - Dense, S -- Sparse, Sparse, CC -- Connected, Connected, LL -- Local, Local, PP -- Pruned Pruned RR -- RP-bit set, RP-bit set, FF -- Register Register flag, flag, TT -- SPT-bit SPT-bit set, set, JJ -- Join Join SPT SPT Timers: Uptime/Expires Timers: Uptime/Expires Interface state: Interface, Next-Hop, State/Mode Interface state: Interface, Next-Hop, State/Mode (*, (*, 224.2.130.100), 224.2.130.100), 00:18:53/00:02:59, 00:18:53/00:02:59, RP RP 0.0.0.0, 0.0.0.0, flags: flags: DD Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Fddi1/0, Fddi1/0, Forward/Dense, Forward/Dense, 00:09:20/00:02:38 00:09:20/00:02:38 Hssi3/0, Hssi3/0, Forward/Dense, Forward/Dense, 00:18:53/00:00:00 00:18:53/00:00:00 (208.197.169.209/32, (208.197.169.209/32, 224.2.130.100), 224.2.130.100), 00:18:53/00:02:27, 00:18:53/00:02:27, flags: flags: TT Incoming Incoming interface: interface: Hssi3/0, Hssi3/0, RPF RPF nbr nbr 131.119.26.9 131.119.26.9 Outgoing Outgoing interface interface list: list: Fddi1/0, Fddi1/0, Forward/Dense, Forward/Dense, 00:16:16/00:02:38 00:16:16/00:02:38 (*, 239.100.111.224), (*, 239.100.111.224), 05:35:08/00:02:58, 05:35:08/00:02:58, RP RP 171.69.10.13, 171.69.10.13, flags: flags: DP DP Incoming interface: Null, RPF Incoming interface: Null, RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing interface list: Null Outgoing interface list: Null
Module4. ppt
8/10/2001 1:55 PM
12 12
Partial output taken from a production router in Ciscos network for more interesting output This is a generic multicast routing table Note the:
(*,G) and (S,G) entries incoming interface outgoing interface list (OIF) RP (if any) Flags times - how long the entry has been in the table and when it will expire
Module4.ppt
12
Module4. ppt
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
Module4.ppt
13
Module4. ppt
8/10/2001 1:55 PM
14 14
Module4.ppt
14
show ip mcache
R6#show R6#show ip ip mcache mcache IP IP Multicast Multicast Fast-Switching Fast-Switching Cache Cache (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Ethernet1, Ethernet1, Last Last used: used: 00:02:33 00:02:33 Serial0 MAC Header: Serial0 MAC Header: 0F000800 0F000800 Serial1 MAC Header: 0F000800 Serial1 MAC Header: 0F000800
Module4. ppt
8/10/2001 1:55 PM
15 15
Displays IPmc fast switching cache - useful for debugging fast switching bugs
Module4.ppt
15
sh ip pim rp mapping
sjck-rp1>show sjck-rp1>show ip ip pim pim rp rp mapping mapping PIM -to-RP PIM Group Group -to-RP Mappings Mappings This system is an RP (Auto -RP) This system is an RP (Auto -RP) This This system system is is an an RP-mapping RP-mapping agent agent (Loopback1) (Loopback1) Group(s) Group(s) 224.0.0.0/4 224.0.0.0/4 RP sj-mbone-loopback0. cisco .com), RP 171.69.10.13 171.69.10.13 (( sj-mbone-loopback0. cisco .com), v2v1 v2v1 Info sj-mbone-loopback0. cisco .com), Info source: source: 171.69.10.13 171.69.10.13 (( sj-mbone-loopback0. cisco .com), via via Auto-RP Auto-RP Uptime: 4w4d, expires: 00:02:55 Uptime: 4w4d, expires: 00:02:55 Group(s) 239.192.111.0/24 Group(s) 239.192.111.0/24 RP cisco.com), RP 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1. cisco.com), v2v1 v2v1 Info cisco.com), Info source: source: 192.168.165.15 192.168.165.15 (sjc25b-00rp-gw1-loop1. (sjc25b-00rp-gw1-loop1. cisco.com), via via Auto-RP Auto-RP Uptime: 1d18h, expires: 00:02:35 Uptime: 1d18h, expires: 00:02:35
Module4. ppt
8/10/2001 1:55 PM
16 16
This command lists the contents of the Group-to-RP Mapping Cache. In the example above, there are two group ranges covered by two different RPs, both of which have been learned via Auto-RP. (RPs can be learned either dynamically or by static configuration.) Note that there can be multiple RPs in the network each supporting a different multicast address range
Module4.ppt
16
show ip sdr
dallas-gw>show dallas-gw>show ip ip sdr sdr SDR SDR Cache Cache -- 450 450 entries entries *cisco *cisco 100k 100k Field Field *cisco *cisco 100K 100K Field Field Sales Sales Office Office *cisco 500k San *cisco 500k San Jose Jose && RTP RTP *cisco 500k SJ and RTP *cisco 500k SJ and RTP
. . . . . .
By default, sdr cache entries are not deleted - use the command ip sdr cache-timeout <minutes> to remove cache entries after a period of time.
Module4. ppt
8/10/2001 1:55 PM
17 17
Module4.ppt
17
18 18
show ip sd [group | "session-name" | detail] Displays the contents of the session directory cache Example shown is an advertisement of a Cisco- internal IP/TV broadcast
Module4.ppt
18
Module4. ppt
8/10/2001 1:55 PM
19 19
Module4.ppt
19
debug ip igmp
R4# R4# debug debug ip ip igmp igmp IGMP: IGMP: Send Send v2 v2 Query Query on on Ethernet1 Ethernet1 to to 224.0.0.1 224.0.0.1 IGMP: .1 IGMP: Received Received v2 v2 Report Report from from 172.16.7.2 172.16.7.2 (Ethernet1) (Ethernet1) for for 224.1.1 224.1.1 .1 IGMP: Received v2 Query from 172.16.6.1 IGMP: Received v2 Query from 172.16.6.1 (Ethernet0) (Ethernet0) IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth ernet0 IGMP: Set report delay time to 2.2 seconds for 224.0.1.40 on Eth ernet0 IGMP: IGMP: Send Send v2 v2 Report Report for for 224.0.1.40 224.0.1.40 on on Ethernet0 Ethernet0 IGMP: .40 IGMP: Received Received v2 v2 Report Report from from 172.16.6.1 172.16.6.1 (Ethernet0) (Ethernet0) for for 224.0.1 224.0.1 .40 IGMP: Received v2 Report from 172.16.6.1 .40 IGMP: Received v2 Report from 172.16.6.1 (Ethernet0) (Ethernet0) for for 224.0.1 224.0.1 .40
Module4. ppt
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
Module4.ppt
20
debug ip mpacket
R6# R6# debug debug ip ip mpacket mpacket 224.1.1.1 224.1.1.1 detail detail IP: IP: MAC MAC sa=00e0.b063.cf4b sa=00e0.b063.cf4b (Ethernet1), (Ethernet1), IP IP last-hop=172.16.12.2 last-hop=172.16.12.2 IP: IP tos=0x0, len =100, id=0x175, IP: IP tos=0x0, len =100, id=0x175, ttl=254, ttl=254, prot=1 prot=1 IP: s=172.16.12.2 (Ethernet1) d=224.1.1.1 len IP: s=172.16.12.2 (Ethernet1) d=224.1.1.1 len 114, 114, mroute mroute olist olist null null
Module4. ppt
8/10/2001 1:55 PM
21 21
Decode of a multicast packet USE CAUTION - when turning on packet level debugging especially when the router is servicing high multicast loads!
Module4.ppt
21
debug ip mroute
R6# R6# debug debug ip ip mrouting mrouting 224.1.1.1 224.1.1.1 MRT: MRT: Create Create (*, (*, 224.1.1.1), 224.1.1.1), RPF RPF Null, Null, PC PC 0x6032D254 0x6032D254 MRT: MRT: Create Create (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), RPF RPF Ethernet1/0.0.0.0, Ethernet1/0.0.0.0, PC PC x6032D378 x6032D378
Module4. ppt
8/10/2001 1:55 PM
22 22
Module4.ppt
22
debug ip pim
R4# R4# debug debug ip ip pim pim 224.1.1.1 224.1.1.1 PIM: -Query PIM: Send Send Router Router -Query on on Ethernet0 Ethernet0 PIM: -Query PIM: Send Send Router Router -Query on on Ethernet1 Ethernet1 PIM: Received Router-Query PIM: Received Router-Query on on Ethernet0 Ethernet0 from from 172.16.6.1 172.16.6.1
Module4. ppt
8/10/2001 1:55 PM
23 23
Periodic Router-Query messages used to keep track of PIM neighbors. This creates and maintains neighbor adjacencies. There is no other PIM router on E1/1 but R3 is seen on E0/0
Module4.ppt
23
Module4. ppt
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.
Module4.ppt
24
R1# R1# PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: -list: -bit PIM: Join Join -list: (*, (*, 224.1.1.1) 224.1.1.1) RP RP 172.16.8.1, 172.16.8.1, RP-bit RP-bit set, set, SS -bit set set PIM: PIM: Add Add Serial0/172.16.3.2 Serial0/172.16.3.2 to to (*, (*, 224.1.1.1), 224.1.1.1), Forward Forward state state PIM: PIM: Received Received Join/Prune Join/Prune on on Serial0 Serial0 from from 172.16.3.2 172.16.3.2 PIM: PIM: Building Building Join/Prune Join/Prune message message for for 224.1.1.1 224.1.1.1 PIM: PIM: Send Send RP-reachability RP-reachability for for 224.1.1.1 224.1.1.1 on on Serial0 Serial0
Module4. ppt
8/10/2001 1:55 PM
25 25
On R1, which the RP for the Group 224.1.1.1 The RP receives periodic JOIN's for the (*,G) which is the pre-existing state in PIM Sparse mode. The RP updates its OIF for the (*,G) and sends back an RP-Reachability message.
Module4.ppt
25
PIM: PIM: Received Received Join/Prune Join/Prune on on Ethernet0 Ethernet0 from from 172.16.9.1 172.16.9.1 PIM: -list: PIM: Join Join -list: (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), S-bit S-bit set set PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, rward PIM: Add Ethernet0/172.16.9.1 to (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Fo Fo rward state state PIM: Building Join/Prune message for 224.1.1.1 PIM: Building Join/Prune message for 224.1.1.1 PIM: No sources in join or prune list PIM: No sources in join or prune list PIM: PIM: Received Received Join/Prune Join/Prune on on Serial1 Serial1 from from 172.16.11.2 172.16.11.2 PIM: -list: PIM: Join Join -list: (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), S-bit S-bit set set PIM: ard PIM: Add Add Serial1/172.6.11.2 Serial1/172.6.11.2 to to (172.16.12.2/32, (172.16.12.2/32, 224.1.1.1), 224.1.1.1), Forw Forw ard state state PIM: PIM: Send Send Null Null Register Register to to 172.16.8.1 172.16.8.1 PIM: PIM: Received Received Register-Stop Register-Stop on on Ethernet0 Ethernet0 from from 172.16.8.1 172.16.8.1
Module4. ppt
8/10/2001 1:55 PM
26 26
Taken from R4 (router connected to the source) - this will show the initiation of the shared tree in PIM sparse mode Part 1 - When the Source initiates transmission to Group 224.1.1.1 R4 uses its (*,G) entry and sends the data to the RP encapsulated i n Register packets for the Source 172.16.12.2. Part 2 - It then creates a (S,G) entry of the form (172.16.12.2/24,224.1.1.1) JOIN's from its PIM Neighbors come in causing the interfaces on which the JOIN's are received to be added to the OIF -list in the Mroute table. Part 3 - R4 now starts sending periodic Null Register messages to the RP and receives Register-Stop messages. This is for maintenance of the tree.
Module4.ppt
26
8/10/2001 1:55 PM
27 27
On R1 (the RP) The RP receives the Register messages from Router R4, it decapsulates the data from the Source and forwards it down the tree towards the Receiver using the pre-existing (*,224.1.1.1) state. Sends a JOIN towards the Source for (S,G)-> (172.16.12.2,224.1.1.1) This builds the (S,G) mtree from the RP to the Source. (the stop the encapsulated data flow to a native IPmc flow) Meanwhile the (*,G) is periodically renewed by the routers on the Receiver side of the mtree. The RP continues to send out periodic JOIN's for (S,G) to maintain state. The RP continues to receive the Null Register messages sent out by R6. The RP then receives a PRUNE from R5 for (S,G) with the RP bit set. The RP bit indicates that the tree is switching from a Shared tree to the Shortest Path tree (SPT). The S bit also signifies the switch.
Copyright ? ?1998-2001, Cisco Systems, Inc.
Module4.ppt
27
Module4. ppt
8/10/2001 1:55 PM
28 28
Module4.ppt
28
Based on Unix mtrace command Split into two separate commands Both use the same mechanism
draft-ietf-idmr-traceroute-ipm-xx.txt
Module4. ppt
8/10/2001 1:55 PM
29 29
Module4.ppt
29
mtrace/mstatHow it works
src
First-hop Router
Multicast Dist. Tree Mtrace Packet
mt rac e res po ns e
dest
st ue req
Last-hop Router
e rac mt
Note: Mtracepackets use special IGMP packets with IGMP Type codes of 0x1E and 0x1F.
Module4. ppt
30 30
Module4.ppt
30
mtrace/mstatHow it works
Uses a special IGMP packet type
IGMP type 0x1F = IGMP type 0x1E = Queries/Requests Response
8/10/2001 1:55 PM
31 31
Module4.ppt
31
mtrace/mstatHow it works
Each hop adds data to packet
Module4. ppt
Query arrival time Incoming Interface Outgoing Interface Prev. Hop Router address Input packet count Output packet count Total packets for this Source/Group Routing Protocol TTL Threshold Forwarding/Error Code
8/10/2001 1:55 PM
32 32
Module4.ppt
32
mtrace/mstatHow it works
Module4. ppt
8/10/2001 1:55 PM
33 33
Module4.ppt
33
mtrace
Shows:
Multicast path from source to receiver.
Similar to unicast trace command Trace path between any two points in network TTL Thresholds & Delay shown at each node
Troubleshooting Usage:
Find where multicast traffic flow stops.
Focus on router where flow stops
8/10/2001 1:55 PM
34 34
Module4.ppt
34
mtrace
dallas-gw>mtrace dallas-gw>mtrace bloom-iptv-svr bloom-iptv-svr bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Type escape sequence to abort. Type escape sequence to abort. Mtrace Mtrace from from 172.17.67.43 172.17.67.43 to to 171.68.37.121 171.68.37.121 via via group group 224.2.156.43 224.2.156.43 From From source source (?) (?) to to destination destination (bwilliam-ss5.cisco.com) (bwilliam-ss5.cisco.com) Querying Querying full full reverse reverse path... path... 0 0 bwilliam-ss5 bwilliam-ss5 (171.68.37.121) (171.68.37.121) -1 -1 dallas-gw dallas-gw (171.68.37.1) (171.68.37.1) PIM PIM thresh^ thresh^ 0 0 3 3 ms ms -2 -2 wan-gw4 wan-gw4 (171.68.86.193) (171.68.86.193) PIM PIM thresh^ thresh^ 0 0 32 32 ms ms -3 -3 bloomington-mn-gw bloomington-mn-gw (171.68.27.2) (171.68.27.2) PIM PIM thresh^ thresh^ 0 0 717 717 ms ms -4 -4 bloom-mnlab bloom-mnlab (171.68.39.28) (171.68.39.28) PIM PIM thresh^ thresh^ 0 0 730 730 ms ms -5 -5 bloom-iptv-svr bloom-iptv-svr (172.17.67.43) (172.17.67.43) dallas-gw> dallas-gw>
Module4. ppt
8/10/2001 1:55 PM
35 35
Shows all active groups with an aggregate bandwidth greater than the specified kbps (4kbps is the default) Listed in each entry is:
group address session name source address and domain name averaged pps and kbps rates for this flow
Module4.ppt
35
mstat
Shows:
Multicast path in pseudo graphic format.
Trace path between any two points in network Drops/Duplicates shown at each node TTLs & Delay shown at each node
Troubleshooting Usage:
Locate congestion point in the flow.
Focus on router with high drop/duplicate count Duplicates indicated as negative drops
Module4. ppt
8/10/2001 1:55 PM
36 36
Module4.ppt
36
mstat
dallas-gw>mstat dallas-gw>mstat 172.17.67.43 172.17.67.43 bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Source Response Packet Source Response Dest Dest Packet Statistics Statistics For For 172.17.67.43 171.68.86.194 All 172.17.67.43 171.68.86.194 All Multicast Multicast Traffic Traffic | __/ Lost/Sent | __/ rtt rtt 547 547 ms ms Lost/Sent = = Pct Pct Rate Rate v / hop --------------------v / hop 547 547 ms ms --------------------172.17.67.33 172.17.67.33 171.68.39.28 bloom 171.68.39.28 bloom-mnlab -mnlab | ^ ttl 0 | ^ ttl 0 v | hop -11/168 v | hop -409 -409 ms ms -11/168 = = --% --% 16 16 pps pps 171.68.39.1 171.68.39.1 171.68.27.2 bloomington-mn-gw 171.68.27.2 bloomington-mn-gw | ^ ttl 1 | ^ ttl 1 v | hop -9/170 17 v | hop 379 379 ms ms -9/170 = = --% --% 17 pps pps 171.68.27.1 171.68.27.1 171.68.86.193 wan 171.68.86.193 wan-gw4 -gw4 | ^ ttl 2 | ^ ttl 2 v | hop ms -3/195 19 v | hop 28 28 ms -3/195 = = --% --% 19 pps pps 171.68.86.194 171.68.86.194 171.68.37.1 dallas-gw 171.68.37.1 dallas-gw | \__ ttl 3 | \__ ttl 3 v \ ms 196 19 v \ hop hop 0 0 ms 196 19 pps pps 171.68.37.121 171.68.86.194 171.68.37.121 171.68.86.194 Receiver Query Receiver Query Source Source
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Only Only For For Traffic Traffic From From 172.17.67.43 172.17.67.43 To To 224.2.156.43 224.2.156.43 ---------------------------------------
0/67 0/67 = = 0% 0%
6 6 pps pps
6 6 pps pps
0/70 0/70 = = 0% 0%
7 7 pps pps
70 70
7 7 pps pps
8/10/2001 1:55 PM
37 37
Shows all active groups with an aggregate bandwidth greater than the specified kbps (4kbps is the default) Listed in each entry is:
group address session name source address and domain name averaged pps and kbps rates for this flow
Module4.ppt
37
mstat
dallas-gw>mstat dallas-gw>mstat 172.17.67.43 172.17.67.43 bwilliam-ss5 bwilliam-ss5 224.2.156.43 224.2.156.43 Source Response Packet Source Response Dest Dest Packet Statistics Statistics For For 172.17.67.43 171.68.86.194 All 172.17.67.43 171.68.86.194 All Multicast Multicast Traffic Traffic | __/ Lost/Sent | __/ rtt rtt 399 399 ms ms Lost/Sent = = Pct Pct Rate Rate v / hop --------------------v / hop 399 399 ms ms --------------------172.17.67.33 172.17.67.33 171.68.39.28 bloom 171.68.39.28 bloom-mnlab -mnlab | ^ ttl 0 | ^ ttl 0 v | hop 77/694 v | hop 119 119 ms ms 77/694 = = 11% 11% 69 69 pps pps 171.68.39.1 171.68.39.1 171.68.27.2 bloomington-mn-gw 171.68.27.2 bloomington-mn-gw | ^ ttl 1 | ^ ttl 1 v | hop 395/609 v | hop -150 -150 ms ms 395/609 = = 65% 65% 60 60 pps pps 171.68.27.1 171.68.27.1 171.68.86.193 wan 171.68.86.193 wan-gw4 -gw4 | ^ ttl 2 | ^ ttl 2 v | hop ms -8/39 3 v | hop 30 30 ms -8/39 = = --% --% 3 pps pps 171.68.86.194 171.68.86.194 171.68.37.1 dallas-gw 171.68.37.1 dallas-gw | \__ ttl 3 | \__ ttl 3 v \ ms 39 3 v \ hop hop 0 0 ms 39 3 pps pps 171.68.37.121 171.68.86.194 171.68.37.121 171.68.86.194 Receiver Query Receiver Query Source Source
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Only Only For For Traffic Traffic From From 172.17.67.43 172.17.67.43 To To 224.2.156.43 224.2.156.43 ---------------------------------------
0/65 0/65 = = 0% 0%
6 6 pps pps
6 6 pps pps
2 2 pps pps
22 22
2 2 pps pps
8/10/2001 1:55 PM
38 38
Module4.ppt
38
mrinfo
berwyn-gw>mrinfo -gw berwyn-gw>mrinfo berwyn berwyn -gw 171.68.56.1 -gw.cisco.com) 171.68.56.1 (berwyn (berwyn -gw.cisco.com) [version [version cisco cisco 11.2] 11.2] [flags: [flags: PMSA]: PMSA]: 171.68.56.97 querier/leaf] 171.68.56.97 -> -> 0.0.0.0 0.0.0.0 [1/0/pim/ [1/0/pim/ querier/leaf] 171.68.56.1 171.68.56.1 -> -> 0.0.0.0 0.0.0.0 [1/0/pim/querier/leaf] [1/0/pim/querier/leaf] 171.68.28.142 171.68.28.142 -> -> 171.68.28.141 171.68.28.141 (wan-gw6.cisco.com) (wan-gw6.cisco.com) [1/0/pim] [1/0/pim]
Module4. ppt
8/10/2001 1:55 PM
39 39
Used to query a peering router about multicast information Example shown is from the Cisco internal network on a remote office router - when no arguments are given - the router queries itself
Module4.ppt
39
ping
ISP-251#ping ISP-251#ping 224.1.1.1 224.1.1.1 Type Type escape escape sequence sequence to to abort. abort. Sending -byte Sending 1, 1, 100 100 -byte ICMP ICMP Echos Echos to to 224.1.1.1, 224.1.1.1, timeout timeout is is 22 seconds: seconds: Reply Reply to to request request 00 from from 172.16.12.2, 172.16.12.2, 16 16 ms ms Reply Reply to to request request 00 from from 172.16.7.2, 172.16.7.2, 20 20 ms ms
Module4. ppt
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
40
You can view {source, group} traffic pairs IP ident and ttl Inter-packet delay Commands
ip multicast cache-headers show ip mpacket <source> <group> [detail]
Module4. ppt
8/10/2001 1:55 PM
41 41
Module4.ppt
41
Module4. ppt
8/10/2001 1:55 PM
42 42
Module4.ppt
42
Debugging Strategies
What does the network look like when everything is working? What is the expected behavior? What specifically is not working? Was it ever working correctly? What has been changed?
Module4. ppt
8/10/2001 1:55 PM
43 43
Debugging Strategies
These are standard questions to consider when debugging anything, including multicast
Module4.ppt
43
Packet Flow
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
44
Check interface counters on host Check upstream router for traffic flow
show ip mroute count show ip mroute active
Module4. ppt
8/10/2001 1:55 PM
45 45
Module4.ppt
45
Most complex piece Depends of protocol, mode, etc. Check initial flow creation Check for pruning and timer expiration during session
Module4. ppt
8/10/2001 1:55 PM
46 46
Module4.ppt
46
show/debug ip mroute commands show/debug ip pim commands show/debug ip dvmrp commands show ip rpf
watch oilist for null entries
Module4. ppt
8/10/2001 1:55 PM
47 47
Module4.ppt
47
Module4. ppt
8/10/2001 1:55 PM
48 48
Module4.ppt
48
DVMRP troubleshooting
show ip dvmrp route
can include address or interface arguments
debug ip dvmrp
Optional arguments are: detail - to capture headers ACL - to specify specific routes in | out - transmitted or recd only pruning - watch pruning and grafting only
Module4. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 1:55 PM
49 49
Module4.ppt
49
mstat command ping command show ip mroute count show ip mroute active debug ip mpacket
Be Careful with this one!
Module4. ppt
8/10/2001 1:55 PM
50 50
Module4.ppt
50
show ip igmp interface show ip igmp groups debug ip igmp / cgmp IGMPv1 vs. IGMPv2
Module4. ppt
8/10/2001 1:55 PM
51 51
Module4.ppt
51
Check receiver interface stats Is the stack installed and configured properly? Is the application installed and configured properly? Watch for duplicates
performance implication
Module4. ppt
8/10/2001 1:55 PM
52 52
Module4.ppt
52
Module4. ppt
53
Module4.ppt
53
Module5. ppt
8/10/2001 2:37 PM
Module5.ppt
Module Objectives
Identify and explain the basic mechanisms of PIM Sparse Mode. Configure and verify normal PIM SM operation.
Module5. ppt
8/10/2001 2:37 PM
2 2
Module5.ppt
Module Agenda
Geekometer
Module5. ppt
8/10/2001 2:37 PM
3 3
Module5.ppt
8/10/2001 2:37 PM
4 4
Module5.ppt
Only one RP is chosen for a particular group RP statically configured or dynamically learned (Auto-RP or PIM v2 BSR) Data forwarded based on the source state (S, G) if it exists, otherwise use the shared state (*, G) RFC 2362 - PIM Sparse Mode Protocol Spec
Module5. ppt
8/10/2001 2:37 PM
5 5
RP Configuration
RPs may be configured statically on each router (although they must all agree or your network will be broken!) in your network. However, a better solution is to use the Auto-RP or PIMv2 mechanisms to configure RPs.
Data Forwarding
Multicast traffic forwarding In a PIM Sparse mode network is first attempted using any matching (S,G) entries in the Multicast Routing table. If no matching (S,G) state exists, then the traffic is forwarded using the matching (*,G) entry in the Multicast Routing table.
Module5.ppt
RP
Module5. ppt
8/10/2001 2:37 PM
6 6
Module5.ppt
Source
RP
(unicast)
Receiver
Module5. ppt
8/10/2001 2:37 PM
7 7
Module5.ppt
Source
RP
(S, G) Register (S, G) Joins Shared Tree Source Tree (S, G) Register-Stop
(unicast)
(unicast)
Receiver
Module5. ppt
8/10/2001 2:37 PM
8 8
Module5.ppt
Source
RP
Source traffic flows natively along SPT to RP. From RP, traffic flows down the Shared Tree to Receivers.
Module5. ppt
8/10/2001 2:37 PM
9 9
Module5.ppt
Source
RP
Last-hop router joins the SPT. (S, G) Joins Shared Tree Source Tree (S, G)RP-bit Prunes Additional (S, G) State is created along new part of the Source Tree. Receiver Additional (S, G) State is created along along the Shared Tree to prune off (S, G) traffic.
Module5. ppt
8/10/2001 2:37 PM
10 10
Module5.ppt
10
Source
RP
(S, G) Traffic flow is now pruned off of the Shared Tree and is flowing to the Receiver via the SPT.
Module5. ppt
8/10/2001 2:37 PM
11 11
Module5.ppt
11
Source
RP
(S, G) traffic flow is no longer needed by the RP so it Prunes the flow of (S, G) traffic.
Module5.ppt
8/10/2001 2:37 PM
12 12
Module5.ppt
12
Source
RP
(S, G) Traffic flow is now only flowing to the Receiver via a single branch of the Source Tree.
Module5.ppt
8/10/2001 2:37 PM
13 13
Module5.ppt
13
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
14 14
Module5.ppt
14
PIMv2 Hellos are periodically multicast to the All-PIM-Routers (224.0.0.13) group address. (Default = 30 seconds)
Note: PIMv1 multicasts PIM Query messages to the All-Routers (224.0.0.2) group address.
If the DR times-out, a new DR is elected. The DR is responsible for sending all Joins and Register messages for any receivers or senders on the network.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
15 15
Module5.ppt
15
Uptime Uptime 2w1d 2w1d 2w6d 2w6d 7w0d 7w0d 7w0d 7w0d 7w0d 7w0d 22:47:11 22:47:11 22:47:22 22:47:22 22:47:07 22:47:07 1d04h 1d04h 1w4d 1w4d 1d04h 1d04h 12:53:25 12:53:25
Expires Expires 00:01:24 00:01:24 00:01:01 00:01:01 00:01:14 00:01:14 00:01:13 00:01:13 00:01:02 00:01:02 00:01:16 00:01:16 00:01:08 00:01:08 00:01:21 00:01:21 00:01:06 00:01:06 00:01:25 00:01:25 00:01:20 00:01:20 00:01:03 00:01:03
Mode Mode Sparse Sparse Sparse Sparse (DR) (DR) Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse Sparse
Module5. ppt
8/10/2001 2:37 PM
16 16
Module5.ppt
16
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
17 17
Module5.ppt
17
PIM State
Describes the state of the multicast distribution trees as understood by the router at this point in the network. Represented by entries in the multicast routing (mroute) table
Used to make multicast traffic forwarding decisions Composed of (*, G) and (S, G) entries Each entry contains RPF information
Incoming (i.e. RPF) interface RPF Neighbor (upstream)
Module5. ppt
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.
Module5.ppt
18
Module5. ppt
8/10/2001 2:37 PM
19 19
19
(*,G) deletion
When OIL = NULL and no child (S,G) state exists
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
20 20
Module5.ppt
20
(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
Module5.ppt
21
8/10/2001 2:37 PM
22 22
Module5.ppt
22
8/10/2001 2:37 PM
23 23
Module5.ppt
23
S C L P T
= = = = =
Sparse Mode Directly Connected Host Local (Router is member) Pruned (All intfcs in OIL = Prune) Forwarding via SPT
Module5. ppt
8/10/2001 2:37 PM
24 24
Module5.ppt
24
In (*, G) entry
In (S, G) entry
Indicates SPT joined due to SPT-Threshold If rate < SPT-Threshold, switch back to Shared Tree
F = Register
In (S,G) entry
S is a directly connected source Triggers the Register Process
In (*, G) entry
Set when F set in at least one child (S,G)
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
25 25
Module5.ppt
25
Module5. ppt
8/10/2001 2:37 PM
PIM-SM Flags
R Flag (RP-Bit) This flag is set on (S, G) entries only and indicates that the (S, G) forwarding information in the entry is applicable to (S, G) traffic flowing down the Shared Tree. The R flag is set on an (S, G) entry by the receipt of an (S, G)RP-bit Prune message. These messages are sent by downstream routers on the Shared Tree that are requesting that this specific (S, G) traffic flow be pruned off of the Shared Tree. This is done to eliminate duplicate (S, G) traffic after a downstream router has switched to the (S, G) Shortest-Path Tree. Whenever the R flag is set on an (S, G) entry, the RPF information must be changed to point toward the RP instead of pointing at source S. This is done because the (S, G) entry is now applicable to (S, G) traffic arriving down the Shared Tree. As a result, the RPF information must point up the Shared Tree in order for arriving (S, G) packets to RPF correctly. (This should be made clear later.)
Module5.ppt
26
Module5. ppt
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.)
Module5.ppt
27
8/10/2001 2:37 PM
28 28
PIM-SM Flags
M Flag (MSDP Created) This flag only appears on (S, G) entries and only on the router that is the active RP for group G. The flag indicates that the RP has learned of this particular source via an MSDP Source Active message. (MSDP is addressed in more detail in another module.) A Flag (Advertise Flag) This flag only appears on (S, G) entries and only on the router that is the active RP for group G. The A flag indicates that this source is in the local PIM-SM domain and that it is a candidate for being announced to RPs in other networks via MSDP Source Active messages. A source is considered to be in the local domain if an (S, G) Register message was received for this source or the source is directly connected to the RP or the (S, G) traffic was received on a Dense mode interface that has been designated as a dense mode boundary interface.
Module5.ppt
28
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
29 29
Module5.ppt
29
PIM SM Joining
ELSE
Join process complete. Reached the Shared Tree.
Module5. ppt
8/10/2001 2:37 PM
30 30
Module5.ppt
30
PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2
S1
rtr-a
E0
10.1.2.1
E0
1 IGMP Join
Rcvr A
E1
rtr-b
Module5. ppt
8/10/2001 2:37 PM
31 31
Module5.ppt
31
PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2
S1
rtr-a
E0
10.1.2.1
E0
E1
Rcvr A
rtr-b
(*, (*, 224.1.1.1), 224.1.1.1), 00:00:05/00:02:54, 00:00:05/00:02:54, RP RP 10.1.5.1, 10.1.5.1, flags: flags: SC SC Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1 10.1.2.1 Outgoing Outgoing interface interface list: list: Ethernet1, Forward/Sparse, 00:00:05/00:02:54 Ethernet1, Forward/Sparse, Forward/Sparse, 00:00:05/00:02:54 00:00:05/00:02:54
Module5. ppt
8/10/2001 2:37 PM
32 32
Module5.ppt
32
PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2
S1
rtr-a
E0
10.1.2.1
E0
2 PIM Join
E1
Rcvr A
rtr-b
1 2
Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends (*,G) Join towards RP.
Module5. ppt
8/10/2001 2:37 PM
33 33
Module5.ppt
33
PIM SM Joining
To RP (10.1.5.1) S0
10.1.4.2 Shared Tree 10.1.2.2
S1
rtr-a
E0
10.1.2.1
E0
E1
Rcvr A
rtr-b
(*, (*, 224.1.1.1), 224.1.1.1), 00:00:05/00:02:54, 00:00:05/00:02:54, RP RP 10.1.5.1, 10.1.5.1, flags: flags: S S Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 10.1.4.1 10.1.4.1 Outgoing Outgoing interface interface list: list: Ethernet0, Ethernet0, 00:00:05/00:02:54 Ethernet0, Forward/Sparse, Forward/Sparse, 00:00:05/00:02:54 00:00:05/00:02:54
Module5. ppt
8/10/2001 2:37 PM
34 34
Module5.ppt
34
PIM SM Joining
To RP (10.1.5.1) 4 Shared Tree S0
10.1.4.2
S1
3 PIM Join
Shared Tree
rtr-a
E0
10.1.2.1
10.1.2.2
E0
E1
Rcvr A
rtr-b
1 2 3 4
Rcvr A wishes to receive group G traffic. Sends IGMP Join for G. rtr-b sends (*,G) Join towards RP. rtr-a sends (*,G) Join towards RP. Shared tree is built all the way back to the RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
35 35
Module5.ppt
35
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
36 36
Module5.ppt
36
PIM SM Registering
Senders begin sourcing Multicast Traffic
Senders dont necessarily perform IGMP group joins.
8/10/2001 2:37 PM
37 37
Module5.ppt
37
Module5. ppt
8/10/2001 2:37 PM
38 38
38
Receivers Join Group First Source Registers First Receivers along the SPT
Module5. ppt
8/10/2001 2:37 PM
39 39
Module5.ppt
39
PIM SM Registering
Receiver Joins Group First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
Shared Tree
(*, 224.1.1.1), 00:03:14/00:02:59, RP 171.68.28.140, flags:S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:03:14/00:02:45 Serial1, Forward/Sparse, 00:03:14/00:02:45
Module5. ppt
8/10/2001 2:37 PM
40 40
Module5.ppt
40
PIM SM Registering
Receiver Joins Group First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
Shared Tree
rtr-b rtr-b>sh >sh ip ip mroute mroute 224.1.1.1 224.1.1.1 No No such such group group
Module5. ppt
8/10/2001 2:37 PM
41 41
Module5.ppt
41
PIM SM Registering
Receiver Joins Group First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
Shared Tree
Module5. ppt
8/10/2001 2:37 PM
42 42
Module5.ppt
42
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets
1
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
RP
rtr-a
rtr-b
rtr-c
Shared Tree
Module5. ppt
8/10/2001 2:37 PM
43 43
Module5.ppt
43
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets
Register Msgs RP
Source 171.68.37.121
E0
S0
S0
S1
S3 S0 S1
rtr-a
rtr-b
rtr-c
Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null PT (171.68.37.121/32, FPT (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, flags: flags: F FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Outgoing Outgoing interface interface list: list: Null Null
Source begins sending group G traffic. rtr-a encapsulates packets in Registers; unicasts to RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
44 44
Module5.ppt
44
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs 171.68.28.139
S0 S3 S0 S1
RP
Source 171.68.37.121
E0
S0
S1
rtr-a
rtr-b
rtr-c
3 (*, 224.1.1.1)
Mcast Traffic Shared Tree
(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:09:21/00:02:38 Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121, 224.1.1.1, 00:01:15/00:02:46, flags: Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial0, Forward/Sparse, 00:00:49/00:02:11 Serial1, Forward/Sparse, 00:00:49/00:02:11
Module5. ppt
8/10/2001 2:37 PM
45 45
Module5.ppt
45
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs (S,G) Join
4 S0
S0 S1
RP
Source 171.68.37.121
E0
S0
S0
S1
rtr-a
rtr-b
Shared Tree
Module5. ppt
8/10/2001 2:37 PM
46 46
Module5.ppt
46
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets (S,G) Join Source 171.68.37.121
E0 S0
Register Msgs
5 S0
S0 S1 S0 S1
RP
rtr-a 171.68.28.190
rtr-b
Shared Tree
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null
(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
Module5. ppt
8/10/2001 2:37 PM
47 47
Module5.ppt
47
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs RP Source 171.68.37.121
E0 S0 S0 S1 S0 S1
rtr-a
rtr-b
Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Registering Outgoing Outgoing interface interface list: list: Serial0, Forward/Sparse, 00:04:28/00:01:32
Module5. ppt
8/10/2001 2:37 PM
48 48
Module5.ppt
48
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs
6
Source 171.68.37.121
E0 S0 S0 S1 S0 S1
RP
rtr-a
rtr-b
7 Register -Stop
Shared Tree
6 7
Module5. ppt
8/10/2001 2:37 PM
49 49
Module5.ppt
49
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets
8
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
RP
rtr-a
rtr-b
Shared Tree (*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Registering Outgoing Outgoing interface interface list: list: Serial0, Serial0, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32
Module5. ppt
8/10/2001 2:37 PM
50 50
Module5.ppt
50
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S0 S1
rtr-a
rtr-b
Shared Tree
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null
(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32
Module5. ppt
8/10/2001 2:37 PM
51 51
Module5.ppt
51
PIM SM Registering
Receiver Joins Group First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
Shared Tree (*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:09:21/00:02:38 Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial0, Forward/Sparse, 00:00:49/00:02:11 Serial1, Forward/Sparse, 00:00:49/00:02:11
8/10/2001 2:37 PM
52 52
Module5.ppt
52
Receivers Join Group First Source Registers First Receivers along the SPT
Module5. ppt
8/10/2001 2:37 PM
53 53
Module5.ppt
53
PIM SM Registering
Source Registers First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
rtr-c rtr-c>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.
Module5. ppt
8/10/2001 2:37 PM
54 54
Module5.ppt
54
PIM SM Registering
Source Registers First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
rtr-b rtr-b>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.
Module5. ppt
8/10/2001 2:37 PM
55 55
Module5.ppt
55
PIM SM Registering
Source Registers First
RP
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
Module5. ppt
8/10/2001 2:37 PM
56 56
Module5.ppt
56
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets
1
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
RP
rtr-a
rtr-b
rtr-c
Module5. ppt
8/10/2001 2:37 PM
57 57
Module5.ppt
57
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets
2 Register Msgs
RP
Source 171.68.37.121
E0
S0
S0
S1
S3 S0 S1
rtr-a
rtr-b
rtr-c
(*, (*, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null PT (171.68.37.121/32, FPT (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:00:03/00:02:56, 00:00:03/00:02:56, flags: flags: F FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Registering Outgoing Outgoing interface interface list: list: Null Null
Source begins sending group G traffic. rtr-a encapsulates packets in Registers; unicasts to RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
58 58
Module5.ppt
58
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs 171.68.28.139
S0 S0 S1 S3 S0 S1
RP
Source 171.68.37.121
E0
3
rtr-c
rtr-a
rtr-b
(*, 224.1.1.1), 00:01:15/00:01:45, RP 171.68.28.140, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Null (171.68.37.121, 224.1.1.1), 00:01:15/00:01:45, flags: P Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Null
Module5. ppt
8/10/2001 2:37 PM
59 59
Module5.ppt
59
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets Register Msgs RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-c
Module5. ppt
8/10/2001 2:37 PM
60 60
Module5.ppt
60
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
rtr-a stops encapsulating traffic in Register Messages; drops packets from Source.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
61 61
Module5.ppt
61
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
(*, (*, 224.1.1.1), 224.1.1.1), 00:01:28/00:01:32, 00:01:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:28/00:01:32, 00:01:28/00:01:32, flags: flags: FPT FPT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0 0.0.0.0 Outgoing Outgoing interface interface list: list: Null Null
8/10/2001 2:37 PM
62 62
Module5.ppt
62
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
rtr-b rtr-b>show >show ip ip mroute mroute 224.1.1.1 224.1.1.1 Group Group 224.1.1.1 224.1.1.1 not not found. found.
Module5. ppt
8/10/2001 2:37 PM
63 63
Module5.ppt
63
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
(*, (*, 224.1.1.1), 224.1.1.1), 00:01:15/00:01:45, 00:01:15/00:01:45, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Null, Null, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121, (171.68.37.121, 224.1.1.1), 224.1.1.1), 00:01:15/00:01:45, 00:01:15/00:01:45, flags: flags: P P Incoming Incoming interface: interface: Serial3, Serial3, RPF RPF nbr nbr 171.68.28.139, 171.68.28.139, Outgoing Outgoing interface interface list: list: Null Null
Module5. ppt
8/10/2001 2:37 PM
64 64
Module5.ppt
64
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
rtr-c
(*, G) Join
Module5. ppt
8/10/2001 2:37 PM
65 65
Module5.ppt
65
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets
7
(S, G) Join RP
S0 S0 S1 S3 S0 S1
Source 171.68.37.121
E0
rtr-a
rtr-b
rtr-c
(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:00:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:14/00:02:46
Module5. ppt
8/10/2001 2:37 PM
66 66
Module5.ppt
66
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets
8
(S, G) Join RP
S1 S3 S0 S1 S0 S0
Source 171.68.37.121
E0
rtr-a 171.68.28.190
rtr-b
rtr-c
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF Outgoing Outgoing interface interface list: list: Null Null
(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
Module5. ppt
8/10/2001 2:37 PM
67 67
Module5.ppt
67
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets
9
Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
RP
rtr-a
rtr-b
rtr-c
10 (*, 224.1.1.1)
Mcast Traffic
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.191, 171.68.28.191, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: FT FT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 0.0.0.0, 0.0.0.0, Outgoing Outgoing interface interface list: list: Serial0, Forward/Sparse, 00:04:28/00:01:32
8/10/2001 2:37 PM
68 68
Module5.ppt
68
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a 171.68.28.190
rtr-b
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 171.68.28.140, 171.68.28.140, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32
8/10/2001 2:37 PM
69 69
Module5.ppt
69
PIM SM Registering
Source Registers First
(171.68.37.121, 224.1.1.1) Mcast Packets 171.68.28.139 RP Source 171.68.37.121
E0 S0 S0 S1 S3 S0 S1
rtr-a
rtr-b
(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11
Module5. ppt
8/10/2001 2:37 PM
70 70
Module5.ppt
70
Receivers Join Group First Source Registers First Receivers along the SPT
Module5. ppt
8/10/2001 2:37 PM
71 71
Module5.ppt
71
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 S3 S1
rtr-a
rtr-b
(*, (*, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, RP RP 171.68.28.140, 171.68.28.140, flags: flags: SP SP Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 171.68.28.140, 171.68.28.140, Outgoing Outgoing interface interface list: list: Null Null (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:04:28/00:01:32, 00:04:28/00:01:32, flags: flags: T T Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF nbr nbr 171.68.28.190 171.68.28.190 Outgoing Outgoing interface interface list: list: Serial1, Serial1, Forward/Sparse, Forward/Sparse, 00:04:28/00:01:32 00:04:28/00:01:32
8/10/2001 2:37 PM
72 72
Module5.ppt
72
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 S3 S1
rtr-a
rtr-b
(*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11
8/10/2001 2:37 PM
73 73
Module5.ppt
73
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1
rtr-a
rtr-b
1 IGMP Join
Rcvr A
Module5. ppt
8/10/2001 2:37 PM
74 74
Module5.ppt
74
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1
rtr-a
rtr-b
Rcvr A (*, 224.1.1.1), 00:04:28/00:01:32, RP 171.68.28.140, flags: SC Incoming interface: Serial1, RPF nbr 171.68.28.140, Outgoing interface list: Ethernet0, Forward/Sparse, 00:00:30/00:02:30 (171.68.37.121/32, 224.1.1.1), 00:04:28/00:01:32, flags: CT Incoming interface: Serial0, RPF nbr 171.68.28.190 Outgoing interface list: Serial1, Forward/Sparse, 00:04:28/00:01:32 Ethernet0, Forward/Sparse, 00:00:30/00:02:30
Added Interfaces
8/10/2001 2:37 PM
75 75
Module5.ppt
75
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0
rtr-a
rtr-b
S3 S1
(*, G) Join
Rcvr A
Module5. ppt
8/10/2001 2:37 PM
76 76
Module5.ppt
76
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1
rtr-a
rtr-b
Rcvr A (*, 224.1.1.1), 00:09:21/00:02:38, RP 171.68.28.140, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial1, Forward/Sparse, 00:03:14/00:02:46 Serial3, Forward/Sparse, 00:00:10/00:02:50 (171.68.37.121/32, 224.1.1.1, 00:01:15/00:02:46, flags: T Incoming interface: Serial3, RPF nbr 171.68.28.139, Outgoing interface list: Serial1, Forward/Sparse, 00:00:49/00:02:11
8/10/2001 2:37 PM
77 77
Module5.ppt
77
PIM SM Registering
Receivers along the SPT
(171.68.37.121, 224.1.1.1) Mcast Packets RP Source 171.68.37.121
S0 S1 E0 S3 S1
rtr-a
rtr-b
3
Rcvr A
Module5. ppt
8/10/2001 2:37 PM
78 78
Module5.ppt
78
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
79 79
Module5.ppt
79
PIM SM SPT-Switchover
SPT Thresholds may be set for any Group
Access Lists may be used to specify which Groups Default Threshold = 0kbps (I.e. immediately join SPT) Threshold = infinity means never join SPT.
Pros
Reduces Network Latency
Cons
More (S,G) state must be stored in the routers.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
80 80
SPT Thresholds
In PIM Sparse mode, SPT Thresholds may be configured to control when to switch to the Shortest-Path Tree (SPT). SPT Thresholds are specified in Kbps and can be used with Access List to specify to which Group(s) the Threshold applies. The default SPT-Threshold is 0Kbps. This means that any and all sources are immediately switched to the Shortest-Path Tree. If an SPT-Threshold of Infinity is specified for a group, the sources will not be switched to the Shortest-Path Tree (SPT) and will remain on the Shared Tree.
PROS
By switching to the Shortest-Path Tree (SPT), the most optimal (usually) path is used to deliver the multicast traffic. Depending on the location of the source in relation to the RP, this switch to the SPT can reduce network latency substantially.
CONS
In networks with large numbers of senders (remember most multicast applications such as IP/TV Client, send RTCP multicast packets in the background and are therefore senders), an increased amount of state must be kept in the routers. In some cases, an Infinity threshold may be used to force certain groups to remain on the Shared Tree when latency is not an issue.
Copyright ? ?1999-2001, Cisco Systems, Inc.
Module5.ppt
80
PIM SM SPT-Switchover
SPT-Switchover Mechanism
Once Once each each second second
Compute Compute new new (*, (*, G) G) traffic traffic rate rate If If threshold threshold exceeded, exceeded, set set J J flag flag in in (*, (*, G) G)
For For each each (S (Sii,, G) G) packet packet received: received:
Module5. ppt
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.
Module5.ppt
81
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 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
8/10/2001 2:37 PM
82 82
Module5.ppt
82
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Serial0, RPF nbr 10.1.4.8, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11
8/10/2001 2:37 PM
83 83
Module5.ppt
83
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 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
8/10/2001 2:37 PM
84 84
Module5.ppt
84
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 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
8/10/2001 2:37 PM
Module5.ppt
85
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11
1 2
Group G rate exceeds SPT Threshold at rtr-b; Set J Flag in (*, G) and wait for next (Si,G) packet.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
86 86
Module5.ppt
86
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1 3
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SCJ Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11
3 4
(Si,G) packet arrives down Shared tree. Clear J Flag in the (*,G) & create (Si,G) state.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
87 87
Module5.ppt
87
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:00:28/00:02:51, flags: C CJT JT Incoming interface: Ethernet0, RPF nbr 10.1.2.1 Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:28/00:02:32
8/10/2001 2:37 PM
88 88
Module5.ppt
88
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
Module5. ppt
8/10/2001 2:37 PM
89 89
Module5.ppt
89
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A
10.1.2.2
E0 E1
rtr-b
Rcvr B (*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:13:28/00:02:53, flags: T Incoming interface: Serial1, RPF nbr 10.1.9.2 Outgoing interface list: Ethernet0, Forward/Sparse, 00:13:25/00:02:30
8/10/2001 2:37 PM
90 90
Module5.ppt
90
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
Module5. ppt
8/10/2001 2:37 PM
91 91
Module5.ppt
91
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
6 7
rtr-a forwards (Si,G) Join toward Si. (Si, G) traffic begins flowing down SPT tree.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
92 92
Module5.ppt
92
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1
(Si,G)RP-bit Prune
rtr-a
S1
To Source Si
S0
10.1.4.2
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
6 7 8
rtr-a forwards (Si,G) Join toward Si. (Si, G) traffic begins flowing down SPT tree. SPT & RPT diverge, triggering (Si,G)RP-bit Prunes toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
93 93
Module5.ppt
93
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A
10.1.2.2
E0 E1
rtr-b
Rcvr B (*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.5.1, Outgoing interface list: Serial1, Forward/Sparse, 00:01:43/00:02:11 Serial2, Forward/Sparse, 00:00:32/00:02:28 (171.68.37.121/32, 224.1.1.1), 00:13:28/00:02:53, flags: R Incoming interface: Serial0, RPF nbr 10.1.5.1 Outgoing interface list: Serial2, Forward/Sparse, 00:00:32/00:02:28
8/10/2001 2:37 PM
94 94
Module5.ppt
94
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 S2
rtr-c
10.1.4.1
S1 9 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
S0
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
Module5. ppt
8/10/2001 2:37 PM
95 95
Module5.ppt
95
PIM SM SPT-Switchover
To RP (10.1.5.1) S0 10 S0 S2
rtr-c
10.1.4.1
S1 S0
10.1.4.2
rtr-a
S1
To Source Si
E010.1.2.1
rtr-d
E0
Rcvr A Rcvr B
10.1.2.2
E0 E1
rtr-b
(Si, G) traffic still flows via other branches of the Shared tree.
Module5. ppt
8/10/2001 2:37 PM
96 96
Module5.ppt
96
PIM SM SPT-Switchover
Shared Tree Switchback Mechanism
Once Once each each minute minute
Module5. ppt
8/10/2001 2:37 PM
97 97
Switchback Algorithm
The Switchback mechanism runs once a minute. (This helps prevent Sources from cycling between Shared Tree and Shortest-Path Tree too rapidly.) For each (Si, G) entry in the Multicast Routing Table that has the J flag set, the mechanism computes the traffic rate for source Si. If the rate has fallen below the SPT-Threshold, a switchback to the Shared Tree is initiated by the last-hop router by: Sending a Join/Prune message that contains a (*, G) Join without a (Si, G)RP -bit Prune, up the Shared Tree (RPT). (This will cause the (Si, G) Prune state along the RPT to be deleted which will permit (Si, G) traffic to begin flowing down the RPT again.) Deleteing its (Si, G) entry in the Multicast Routing Table. Send (Si, G) Prune up the Shortest-Path Tree (SPT) to stop traffic from flowing down the SPT. Note that this Switchback Algorithm is broken in older versions of IOS.
Module5.ppt
97
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
98 98
Module5.ppt
98
PIM SM Pruning
IGMP group times out / last host sends Leave Interface removed from all (*,G) & (S,G) entries
IF all interfaces in oilist for (*,G) are pruned; THEN send Prune up shared tree toward RP Any (S, G) state allowed to time -out
Module5. ppt
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.
Module5.ppt
99
PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
S1
rtr-a
E0
10.1.2.1
10.1.2.2
E0
E1
Rcvr A
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: SC Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: Ethernet1, Forward/Sparse, 00:01:43/00:02:11
Module5. ppt
8/10/2001 2:37 PM
Module5.ppt
100
PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
S1
rtr-a
E0
10.1.2.1
10.1.2.2
E0
E1
Rcvr A
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:13, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11
Module5. ppt
8/10/2001 2:37 PM
101 101
Module5.ppt
101
PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1) S0
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
S1
rtr-a
E0
10.1.2.1
10.1.2.2
E0
3 (*,G) Prune
1 IGMP Leave
Rcvr A
E1 2
rtr-b
1 2 3
rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP.
Module5. ppt
8/10/2001 2:37 PM
102 102
Module5.ppt
102
PIM SM Pruning
Shared Tree Case
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree
(*,G) Prune
X
E1
6 S0
S1
10.1.4.2
rtr-a
10.1.2.2
X
E0
E0 4
10.1.2.1
rtr-b
4 5 6
rtr-a (*,G) oilist now empty; send (*,G) Prune toward RP. Pruning continues back toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
103 103
Module5.ppt
103
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
Rcvr A
rtr-b
(*, (*, 224.1.1.1), 224.1.1.1), 00:01:43/00:02:59, 00:01:43/00:02:59, RP RP 10.1.5.1, 10.1.5.1, flags: flags: SC SC Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1, 10.1.2.1, Outgoing Outgoing interface interface list: list: Ethernet1, Ethernet1, Forward/Sparse, Forward/Sparse, 00:01:43/00:02:11 00:01:43/00:02:11 (171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:05/00:01:55, 00:01:05/00:01:55, flags: flags: CJT CJT Incoming Incoming interface: interface: Ethernet0, Ethernet0, RPF RPF nbr nbr 10.1.2.1 10.1.2.1 Outgoing Outgoing interface interface list: list: Ethernet1, Ethernet1, Forward/Sparse, Forward/Sparse, 00:01:05/00:02:55 00:01:05/00:02:55
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
104 104
Module5.ppt
104
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
Rcvr A
rtr-b
(*, 224.1.1.1), 00:01:43/00:02:59, RP 10.1.5.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:43/00:02:11 (171.68.37.121/32, 224.1.1.1), 00:01:05/00:01:55, flags: T Incoming interface: Serial1, RPF nbr 10.1.9.2 Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:05/00:02:55
8/10/2001 2:37 PM
105 105
Module5.ppt
105
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1 3 (*,G) Prune
10.1.2.2
E0
1 IGMP Leave
Rcvr A
E1 2
rtr-b
1 2 3
rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
106 106
Module5.ppt
106
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
rtr-b
Rcvr A
1 2 3 4
rtr-b is a Leaf router. Last host Rcvr A, leaves group G. rtr-b removes E1 from (*,G) and any (Si,G) oilists. rtr-b (*,G) oilist now empty; sends (*,G) Prune toward RP. rtr-b stops sending periodic (S, G) joins.
1998 2001, Cisco Systems, Inc. All rights reserved.
Module5. ppt
8/10/2001 2:37 PM
107 107
Module5.ppt
107
PIM SM Pruning
Source (SPT) Case
S1
(*,G) Prune (Si, G) Traffic Flow Shared Tree SPT Tree
To Source Si
To RP (10.1.5.1) 6
10.1.4.2
S0
rtr-a
10.1.2.2
E0
E0 10.1.2.1 5
E1
rtr-b
5 6
rtr-a (*,G) oilist now empty; sends (*,G) Prune toward RP.
Module5. ppt
8/10/2001 2:37 PM
108 108
Module5.ppt
108
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
rtr-b
(*, 224.1.1.1), 00:02:32/00:02:59, RP 10.1.5.1, flags: S P Incoming interface: Ethernet0, RPF nbr 10.1.2.1, Outgoing interface list: (171.68.37.121/32, 224.1.1.1), 00:01:56/00:00:53, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.2.1 Outgoing interface list:
8/10/2001 2:37 PM
109 109
Module5.ppt
109
PIM SM Pruning
Source (SPT) Case
S1 S0 To Source Si
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
rtr-b
RP RP 10.1.5.1, 10.1.5.1, flags: flags: S SP P nbr nbr 10.1.4.1, 10.1.4.1,
(*, (*, 224.1.1.1), 224.1.1.1), 00:02:32/00:02:59, 00:02:32/00:02:59, Incoming Incoming interface: interface: Serial0, Serial0, RPF RPF Outgoing interface Outgoing interface list: list:
(171.68.37.121/32, (171.68.37.121/32, 224.1.1.1), 224.1.1.1), 00:01:56/00:00:53, 00:01:56/00:00:53, flags: flags: P PT T Incoming Incoming interface: interface: Serial1, Serial1, RPF RPF nbr nbr 10.1.9.2 10.1.9.2 Outgoing Outgoing interface interface list: list:
8/10/2001 2:37 PM
110 110
Module5.ppt
110
PIM SM Pruning
Source (SPT) Case
(Si,G) Data
To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
S1 S0
7 To Source Si
rtr-a
E0 10.1.2.1
8 (Si,G) Prune
10.1.2.2
E0
E1
rtr-b
7 8
Another (Si,G) data packet arrives via Serial1. rtr-a responds by sending an (Si,G) Prune toward source.
Module5. ppt
8/10/2001 2:37 PM
111 111
Module5.ppt
111
PIM SM Pruning
Source (SPT) Case
9 To RP (10.1.5.1)
(Si, G) Traffic Flow Shared Tree SPT Tree 10.1.4.2
S1 S0
To Source Si
rtr-a
E0 10.1.2.1
10.1.2.2
E0
E1
rtr-b
7 8 9
Another (Si,G) data packet arrives via Serial1. rtr-a responds by sending an (Si,G) Prune toward source. (Si,G) traffic ceases flowing down SPT.
Module5. ppt
8/10/2001 2:37 PM
112 112
Module5.ppt
112
PIM Neighbor Discovery PIM State PIM SM Joining PIM SM Registering PIM SM SPT-Switchover PIM SM Pruning PIM SM State Maintenance
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
113 113
Module5.ppt
113
Periodic Join/Prunes are sent to all PIM neighbors. Periodic Joins refresh interfaces in a PIM neighbors oilists. Periodic Prunes refresh prune state in a PIM neighbor. Received Multicast packets reset (S,G) entry expiration timers.
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
114 114
Module5.ppt
114
RP
Module5. ppt
8/10/2001 2:37 PM
115 115
Module5.ppt
115
RP Join
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
116 116
Module5.ppt
116
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
117 117
Module5.ppt
117
Register
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
118 118
Module5.ppt
118
Join
Join
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
119 119
Module5.ppt
119
Register-Stop
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
120 120
Module5.ppt
120
A (S, G) Join C
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
121 121
Module5.ppt
121
(S, G) Prune
RP
Receiver 1
Module5. ppt
8/10/2001 2:37 PM
122 122
Module5.ppt
122
B (*, G) Join C
RP
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
123 123
Module5.ppt
123
RP
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
124 124
Module5.ppt
124
RP
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
125 125
Module5.ppt
125
RP
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
126 126
Module5.ppt
126
RP
Source 2
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
127 127
Module5.ppt
127
RP
Source 2
Receiver 1
Receiver 2
Module5. ppt
8/10/2001 2:37 PM
128 128
Module5.ppt
128
Anycast/Static RP addressing
RP address must be configured on every router Note: Anycast RP requires MSDP
Module5. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/10/2001 2:37 PM
129 129
Configure the RP
Auto-RP (or BSR) are the simplest forms of RP configuration as they allow the routers in the network to automatically learn the address of the RP. This requires two additional command lines on one or more routers in the network that have been selected as candidate RPs. Configure one or more routers as Candidate RPs using the appropriate Auto-RP or BSR command. Configure one or more routers as Mapping Agents (Auto-RP) or Candidate BSRs (BSR). Anycast/Static RP addressing takes more work as the single RP address must be configured on every router in the network. Anycast RP is a form of redundant static RPs which requires the use of the Multicast Source Discovery Protocol (MSDP) but provides rapid RP failover.
Module5.ppt
129
Module5. ppt
8/10/2001 2:37 PM
130 130
Module5.ppt
130
Module5. ppt
8/10/2001 2:37 PM
131 131
Module5.ppt
131
8/10/2001 2:37 PM
132 132
Module5.ppt
132
Module5. ppt
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
133
Module5. ppt
8/10/2001 2:37 PM
134 134
Module5.ppt
134
Avoiding DM Fallback
To always guarantee Sparse mode operation (and avoid falling back to Dense mode), make sure that every router always knows of an RP for every group.
Module5.ppt
8/10/2001 2:37 PM
135 135
Module5.ppt
135
Avoiding DM Fallback
Define an "RP-of-last-resort.
Configure as a Static RP on every router.
Will only be used if all Candidate-RPs fall. Can be a dummy address.
Recommendation: Use lowest priority C-RP address.
Module5. ppt
8/10/2001 2:37 PM
136 136
Avoiding DM Fallback
In order to guarantee that the router will never fall back into dense mode, it is necessary to guarantee that the router will never loose RP information. This can be accomplished by defining a static, RP-of-last-resort in each router in the network. Since automatically learned RPs (Auto-RP or BSR) take precedence over statically defined RPs, the static entry will only be activated if all learned RPs timeout and/or fail. The recommendation is to define the lowest priority Candidate RP as the RP-of-last-resort by using a static RP definition pointing to this IP address. This locks the lowest priority RP into the bottom of the failover order. Even if this router fails (or its information times out), the static entry in each router will prevent a total loss of RP information. Special care must be taken if an RP -of-last-resort is defined when using Auto-RP. By default, a static RP definition that covers the Auto-RP group range will be interpreted as the RP for the two Auto-RP groups. (Unlike Auto-RP learned group ranges which have an implied deny for these two groups so that the two Auto-RP groups will default to using dense mode.) The following example shows how to configure an RP -of-last-resort so that the two Auto-RP groups do not accidentally switch to sparse mode: ip pim rp-address <RP-of-last-resort> 10 access-list 10 deny 224.0.1.39 access-list 10 deny 224.0.1.40 access-list 10 permit any
Module5.ppt
136
On routers B and C: ip pim send-rp-announce loopback0 scope 16 ip pim send-rp-discovery loopback0 scope 16
Module5. ppt
8/10/2001 2:37 PM
137 137
Module5.ppt
137
Module5.ppt
138
Module5.ppt
138
Rendezvous Points
Module 6
Module6. ppt
8/13/2001 11:12 AM
Module6.ppt
Module Objectives
Explain the basic operation of Auto-RP. Explain the basic operation of PIMv2 BSR. Explain how to configure RPs How to use various IOS commands to tune and control RP operation.
Module6. ppt
Module6.ppt
Module Agenda
Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
Module6.ppt
Auto-RP Overview
All routers automatically learn RP address
No configuration necessary except on:
Candidate RPs Mapping Agents
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.
Module6.ppt
Auto-RP Fundamentals
Candidate RPs
Multicast RP-Announcement messages
Sent to Cisco-Announce (224.0.1.39) group Sent every rp-announce-interval (default: 60 sec)
RP-Announcements contain:
Group Range (default = 224.0.0.0/4) Candidates RP address Holdtime = 3 x <rp-announce-interval>
Module6.ppt
Auto-RP Fundamentals
Mapping agents
Receive RP-Announcements
Stored in Group-to-RP Mapping Cache with holdtimes Elects highest C-RP IP address as RP for group range
Module6.ppt
Auto-RP Fundamentals
Module6. ppt
Module6.ppt
On routers B and C: ip pim send-rp-announce loopback0 scope 16 ip pim send-rp-discovery loopback0 scope 16
Module6. ppt
Module6.ppt
Announce
MA A A
Announce
MA B B
Announce
Announce
Announce
Announce
Announce
C-RP 1.1.1.1
C C
D D
Announce
C-RP 2.2.2.2
Module6. ppt
Module6.ppt
MA A A
Dis cov ery
Disc ove ry
Disc ove ry
MA B B
Disc ove ry
C-RP 1.1.1.1
C C
D D
C-RP 2.2.2.2
Module6. ppt
10 10
Module6.ppt
10
C-RP 1.1.1.1
C-RP 2.2.2.2
Module6. ppt
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.
Module6.ppt
11
A
0/4 .0. 4.0 2 =2 .1 ge ec .1.1 Ran 80 s nce 1 - 1 ou = = RP roup ime Ann G oldt H
C-RP 1.1.1.1
Rtr -A# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49
C-RP 2.2.2.2
C-RP Information is Stored in MAs Group-to-RP Mapping Cache Mapping Agent elects highest IP Address as RP
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
12 12
Auto-RP Up Close
Step 2 Routers C and D begin sending their RP Announce messages advertising themselves as a candidate to be RP for all multicast groups. (Note the group range, the IP address of the C-RP and the holdtime in the message.) Step 3 The Mapping Agent (router A) receives these RP Announcements and stores this information in its Group-to-RP mapping cache. The output of the show ip pim rp mapping command on the Mapping Agent (router A) now shows both router C and D as candidates for group range 224.0.0.0/4 (i.e. all multicast groups with the exception of the Auto-RP groups). The Mapping Agent then elects the C-RP with the highest IP address as the active RP for the group range.
Module6.ppt
12
A
R G P= Ho roup 2.2.2 ldt . im - R 2 e an g = e= Di 180 224 sc se .0. ov c 0.0 ery /4
Module6. ppt
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.
Module6.ppt
13
MA
MA
A
172.16.2.1
B
172.16.2.2
Rtr -A# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49
Rtr -B# show ip pim rp mapping This system is an RP -mapping agent Group(s) 224.0.0.0/4 RP 2.2.2.2 (Rtr (Rtr -D), v2v1 Info source: 2.2.2.2 (Rtr -D), via Auto-R P Uptime: 00:00:03, expires: 00:02:57 RP 1.1.1.1 (Rtr -C), v2v1 Info source: 1.1.1.1 (Rtr -C), via Auto-R P Uptime: 00:00:11, expires: 00:02:49
Module6. ppt
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.
Module6.ppt
14
MA
A
172.16.2.1
B
172.16.2.2
Module6. ppt
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.
Module6.ppt
15
MA
A
172.16.2.1
B
172.16.2.2
Info source will continue to flip-flop between routers A and B No performance impact
X
Module6. ppt
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.
Module6.ppt
16
Module Agenda
Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
17 17
Module6.ppt
17
18 18
BSR Overview
Bootstrap Router (BSR) A single router is elected as the BSR from a collection of Candidate BSRs. If the current BSR fails, a new election is triggered. The election mechanism is pre-emptive based on C-BSR priority. Candidate RPs (C-RPs) Send C-RP announcements directly to the BSR via unicast. (Note: C-RPs learn the IP address of the BSR via periodic BSR messages.) The BSR stores the complete collection of all received C-RP announcements in a database called the RP -set. The BSR periodically sends out BSR messages to all routers in the network to let them know the BSR is still alive. BSR messages are flooded hop-by-hop throughout the network. Multicast to the All-PIM Routers group (224.0.0.13 ) with a TTL of 1. BSR messages also contain: The complete RP-set consisting of all C-RP announcements. The IP Address of the BSR so that C-RPs know where to send their announcements. All routers receive the BSR messages being flooded throughout the network. Select the active RP for each group range using a common hash algorithm that is run against the RP-set. This results in all routers in the network selecting the same RP for a given group-range. BSR cannot be used with Admin-Scoping! Admin scoping was not considered when BSR was designed. One problem is that C-RP announcements that are unicast to the BSR cross multicast boundaries. There are several other problems as well.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 18
Module6. ppt
19 19
Module6.ppt
19
Sent out all interfaces. Propagate hop-by-hop Sent every 60 seconds or when changes detected
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
20
<intfc>
Determines IP address
<hash-length>
Sets RP selection hash mask length
<pri>
Sets the C-BSR priority (default = 0)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
21 21
Module6.ppt
21
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.
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.
Module6. ppt
23 23
Accept-Any State
Accept the first BSR message received and process it as follows: Copy the RP -Set into the local Group-to-RP mapping cache. Save the current BSR priority and BSR address in the BSR message. Transition to the Accept-Preferred state.
Accept-Preferred State
Start the BSR-Timeout timer with a period of 150 seconds. If this timer expires, transition back to the Accept-Any state. Accept only BSR messages that are preferred. (A preferred BSR message is one with a priority greater than or equal to the current BSR priority.) The accepted BSR message is then processed as follows: The BSR-Timeout timer is reset. The BSR message is forwarded out all other interfaces. The RP-set in the BSR message is copied into the local Group-to-RP mapping cache. Save the current BSR priority and BSR address in the BSR message. If a BSR message is received with a priority less than the C-BSRs priority, the BSR message is simply discarded. (Remember, the IP address of the BSR is used to break any ties with the winner being the C-BSR with the highest IP address.)
Module6.ppt
23
Module6. ppt
24 24
F
BSR Msgs
CRP Ad v (un ertise ica me st) nt
BSR
A
BSR Msgs
D
nt me ise ert t) v Ad as RP (unic C-
C-RP
B E
C-RP
Module6. ppt
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.
Module6.ppt
25
Module Agenda
Auto RP PIMv2 BSR Static RPs Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
26 26
Module6.ppt
26
Static RPs
Hard-coded RP address
When used, must be configured on every router All routers must have the same RP address RP fail-over not possible
Exception: If Anycast RPs are used. (See MSDP module.)
Command
ip pim rp-address <address> [group-list <acl>] [override]
Module6. ppt
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.
Module6.ppt
27
Module Agenda
Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
28 28
Module6.ppt
28
RP Placement
Module6. ppt
29 29
Module6.ppt
29
RP Performance Considerations
CPU load factors
RP must process Registers RP must process Shared-tree Joins/Prunes RP must send periodic SPT Joins toward source PIM performs RPF recalculation every 5 seconds
Watch the total number of mroute table entries in the RP Only when spt-threshold = infinity is in use
Shared-tree forwarding
30 30
RP Performance Considerations
CPU Load Factors The RP will receive all Register messages for any new sources in the network. Although processing of Register messages is done at Process Level, the impact on the router is usually small since the RP will immediately send back a Register-Stop message. The RP will receive and must process all Shared Tree Join/Prune messages from downstream routers on the Shared Tree. Downstream routers continue to send periodic (once a minute) Join/Prune messages up the Shared Tree. The number of these Join/Prune messages is generally quite small and therefore has little impact on the RP. The RP must send periodic (once a minute) SPT Joins toward all sources for which it has members active on a branch of the Shared Tree. In order to detect a network topology change, ALL PIM routers perform an RPF recalculation on every (*, G) and (S, G) entry in the mroute table every 5 seconds. The impact of this will grow as the total number of entries in the mroute table increase and as the number of entries in the unicast routing table increase. (The later is due to the fact that each RPF calculation requires the route to the source to be looked up in the unicast routing table. If this table is quite large, as would be the case for poorly aggregated address space, the lookup can take more effort than when the number of entries is kept small.) Except for the following load factor, this is the most significant CPU load factor. Any traffic that does have to flow through the RP requires it to replicate the packets out all outgoing interfaces. Memory Factors The amount of memory consumed by PIM is primarily a function of the size of the mroute table. (See the numbers in the slide for details.)
Copyright ? ?1998-2001, Cisco Systems, Inc. Module6.ppt 30
Increase CPU horsepower Increase memory Use SPTs if not already Split RP load across several RPs!
Module6. ppt
31 31
Module6.ppt
31
32 32
Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpannounce command on the C-RP router. However, the maximum diameter of the network is greater than 16 hops and in this case one Mapping Agent is further away than 16 hops. As a result, this Mapping Agent does not receive the RP Announcement messages from the C-RP. This can cause the two Mapping Agents to have different information in their Group-to-RP mapping caches. If this occurs, each Mapping Agent will advertise a different router as the RP for a group which will have disastrous results. Notice also, that the C-RP is fewer than 16 hops way from the edge of the network. This can result in RP Announcement messages leaking into adjacent networks and causing Auto-RP problems in those networks.
Module6.ppt
32
scope 32 C Candidate-RP
scope 32
A Mapping Agent
Both Mapping Agents Are Now Receiving Announcements from the Candidate RP Network Diameter = 32 Hops
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
33 33
Example
In the above diagram, the maximum network diameter is 32. Therefore by setting the scope to 32 or greater, we are assured that the RP Announcements will reach both Mapping Agents shown in the example network. In order to prevent RP Announcement messages from leaking into adjacent networks, a multicast boundary is defined for the Cisco-Announce (224.0.1.39) multicast group on all border routers in the network. This not only stops RP Announcement messages from leaking out, it more importantly, stops any from leaking in from adjacent networks.
Module6.ppt
33
34 34
Example
In the diagram above, an arbitrary scope of 16 was used in the ip pim send-rpdiscovery command on the Mapping Agent. However, the maximum diameter of the network is greater than 16 hops and in this case, at least one router is further away than 16 hops. As a result, this router does not receive the RP Discovery messages from the MA. This can result in the router having no Group-to-RP mapping information. If this occurs, the router will attempt operate in Dense mode for all multicast groups while other routers in the network are working in Sparse mode. Notice also, that the MA is fewer than 16 hops way from the edge of the network. This can result in RP Discovery messages leaking into adjacent networks and causing Auto-RP problems in those networks.
Module6.ppt
34
scope 32
35 35
Example
In the above diagram, the maximum network diameter is 32. Therefore by setting the scope to 32 or greater, we are assured that the RP Discovery messages will reach the farthest router in the network. In order to prevent RP Discovery messages from leaking into adjacent networks, a multicast boundary is defined for the Cisco-Discovery (224.0.1.40) multicast group on all border routers in the network. This not only stops RP Discovery messages from leaking out, it more importantly, stops any from leaking in from adjacent networks.
Module6.ppt
35
S0
scope 32
scope 32
C Candidate-RP
Module6. ppt
36 36
Module6.ppt
36
Module6. ppt
37 37
Module6.ppt
37
Controlling RP Acceptance
What really determines if a router is the RP
Any router will assume the duties of the RP if:
It receives a (*,G) Join that contains an RP address that is the IP address of one of its interfaces AND The interface is multicast enabled AND The RP address matches the RP in the Group-to-RP mapping cache OR There is no entry in the Group-to-RP mapping cache.
38 38
Module6.ppt
38
Controlling RP Acceptance
Accept-RP Command
Global configuration commands
ip pim accept-rp <rp-address> [<acl>] ip pim accept-rp Auto-rp [<acl>] ip pim accept-rp 0.0.0.0 [<acl>]
Search Rules
Top down search Stop on RP address matchApply ACL and exit Exception: Auto-RP denies RP/Group
Apply 0.0.0.0 (wildcard) entry (if it exists)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
39 39
Command format
ip pim accept-rp <rp-address> [<acl>] ip pim accept-rp Auto-rp [<acl>] ip pim accept-rp 0.0.0.0 [<acl>] The option <acl> is used to specify which groups are valid using standard permit and deny clauses. Omitting the <acl> assumes a permit 224.0.0.0 15.255.255.255. If more than one of the above commands is configured, they are sorted in the order shown above. The Auto-rp entry matches any RP address learned via Auto-RP. (Note: This form has implied deny clauses for the Auto-RP groups, 224.0.1.39 and 224.0.1.40, that cannot be overridden in the optional <acl>. This helps prevent the Auto-RP groups from accidentally switching to Sparse mode.) The 0.0.0.0 (wildcard) matches any RP address. While multiple ip pim accept-rp <rp-address> commands may be configured, only a single Auto-rp and a single 0.0.0.0 (wildcard) command is accepted.
Search Rules
The list of configured commands is searched from top down and stops at the first entry that matches the RP address. The <acl> is applies and the RP is either permitted or denied. Exception: If an Auto-RP entry denies an RP and a 0.0.0.0 entry exists, the 0.0.0.0 entry is also tried.
Module6.ppt
39
Controlling RP Acceptance
Module6. ppt
40 40
Module6.ppt
40
Accept-RPCase 1
Permit Permit
Module6. ppt
41 41
Module6.ppt
41
Accept-RPCase 2
B B
RP RP Address Address
Module6. ppt
42 42
Example
When Auto-RP is in use, it is normally the case that the two Auto-RP groups, 224.0.1.39 and 224.0.1.40 should be operating in Dense mode. However, if a downstream router is misconfigured with a static RP address, it will send (*, G) Joins for these Auto-RP groups. The routers that receive these (*, G) Joins will create a (*,G) entry in Sparse mode for these Auto-RP groups. This can result in portions of the network trying to operate these groups in Dense mode while other parts of the network are operating in Sparse mode. This will generally cause the Auto-RP mechanisms to fail. The following Accept-RP command will cause a router to reject any (*,G) Joins for the Auto-RP groups and prevent these Joins from propagating. ip pim accept-rp Auto-rp
Module6.ppt
42
Accept-RPCase 3
Source S
B B
A A
RP Processing Engine
Permit Permit
RP
Module6. ppt
43 43
Module6.ppt
43
Global command
ip pim rp-announce-filter rp-list <acl> [group-list <acl>] rp-list <acl>
Specifies from which routers C-RP Announcements are accepted.
group-list <acl>
Specifies which groups in the C-RP Announcement are accepted. If not specified, defaults to deny all groups
Module6. ppt
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
44
Used on RP to filter incoming Register messages Filter on Source address alone (Simple ACL) Filter on (S, G) pair (Extended ACL) May use route-map to specify what to filter
Filter by AS-PATH if (m)BGP is in use.
Module6. ppt
Module6.ppt
45
Module Agenda
Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
46 46
Module6.ppt
46
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
47
Module6. ppt
48 48
Module6.ppt
48
Module6. ppt
49 49
Module6.ppt
49
Module Agenda
Static RPs Auto RP PIMv2 BSR Tuning RP Operations Debugging RP Operation Special Cases
Module6. ppt
50 50
Module6.ppt
50
RP on a Stick
Triggering conditions on the RP:
A (*,G) entry (i.e. Shared Tree) exists with a single outgoing interface on the RP. And an (S,G) entry (i.e a Source) exists on the same interface with a Null outgoing interface list.
Mishandled in versions of IOS prior to 12.0 Requires the Proxy Join Timer to resolve Need to understand concept of atomic joins
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
51 51
RP on a Stick
This is a special situation that occurs under the following conditions: All branches of the Shared Tree are out a single interface on the RP (i.e. there is only a single interface in the (*, G) OIL at the RP.) All sources for the group are out the same interface. (This would result in (S, G) entries with Null OILs since the incoming interface can never appear in the OIL of an entry.)
Module6.ppt
51
RP on a Stick
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
Module6. ppt
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.
Module6.ppt
52
RP on a Stick
Shared Tree
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0
(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39
rtr-c
E0
Member 224.1.1.1
Module6. ppt
53 53
RP-on-a-Stick Example
When a host behind rtr-c joins group 224.1.1.1, a branch of the Shared Tree is created (shown by the solid arrow) which results in the following state on the RP: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39
Module6.ppt
53
RP on a Stick
Shared Tree
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SC Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39
Member 224.1.1.1
Module6. ppt
54 54
RP-on-a-Stick Example
This also results in the following state on rtr-c: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SC Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:01:21/00:02:39
Module6.ppt
54
RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
Source 192.1.1.1
Member 224.1.1.1
Module6. ppt
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.
Module6.ppt
55
RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
(*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SP Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: (192.1.1.1/32,Source 224.1.1.1), 00:00:49/00:02:46, flags: T Incoming interface: 192.1.1.1Ethernet0, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:49/00:02:11
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
56 56
RP-on-a-Stick Example
The creation of the SPT results in the following state on rtr-b: (*, 224.1.1.1), 00:01:21/00:02:59, RP 10.1.4.1, flags: SP Incoming interface: Ethernet1, RPF nbr 10.1.4.1, Outgoing interface list: (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: T Incoming interface: Ethernet0, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet1, Forward/Sparse, 00:00:49/00:02:11
Module6.ppt
56
RP on a Stick
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), Source 00:00:49/00:02:46, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, 192.1.1.1 Outgoing interface list:
rtr-c
E0
Member 224.1.1.1
57 57
RP-on-a-Stick Example
The creation of the SPT also results in the following state on the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: PT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Notice that the OIL of the (S, G) entry is Null which, in turn, results in the P flag being set. Normally, this would cause the RP to send an (S, G) Prune toward the source to shut off the flow of (S, G) traffic. However in this case, that would starve the host behind rtr-c of the desired group traffic. Obviously, something else must be done to prevent this.
Module6.ppt
57
RP on a Stick
Module6. ppt
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
Module6.ppt
58
RP on a Stick
Non-Atomic Joins
Contains (*, G) Join for group G only
This is the type of (*, G) Join we are familiar with
Atomic Joins
Contains (*, G) Join for group G followed by (S, G)RP-bit Prunes for all sources in group G
Used to prune unnecessary (S, G) traffic from the Shared Tree after switchover to the SPT.
Module6. ppt
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.
Module6.ppt
59
RP on a Stick
PIM Join/Prune Message
Header (10.1.4.1, 224.1.0.5) (10.1.4.1, 224.1.1.1) (10.1.4.1, 224.2.2.2) Join List (10.1.19.21, 224.2.2.2) . . . (10.1.19.21, 224.1.0.5) (10.1.4.1, 224.3.3.3) (192.1.1.1, 224.1.1.1) Prune List (192.1.4.2, 224.2.2.2) . . .
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
WC, RP WC, RP WC, RP RP (*, G) Join + (S, G)RP-bit Prune = Atomic Join
WC, RP RP
60 60
Module6.ppt
60
RP on a Stick
PIM Join/Prune Message
Header (10.1.4.1, 224.1.0.5) (10.1.4.1, 224.1.1.1) (10.1.4.1, 224.2.2.2) Join List (10.1.19.21, 224.2.2.2) . . . (10.1.19.21, 224.1.0.5) (10.1.4.1, 224.3.3.3) (192.1.1.1, 224.1.1.1) Prune List (192.1.4.2, 224.2.2.2) . . .
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
WC, RP WC, RP WC, RP RP (*, G) Join + NO (S, G)RP-bit Prunes = Non-Atomic Join
WC, RP RP
61 61
Module6.ppt
61
RP on a Stick
Proxy Join Timer
Used on (S, G) entries only Started on the RP by the initial (S, G) Register
If (S, G) OIL is Null AND (*, G) OIL is Non-Null
Controls the sending of (S, G) Joins and Prunes down the SPT When Proxy Join Timer is Running (X flag set)
Send (S, G) Joins down SPT Suppress sending any (S, G) Prunes down SPT
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
62 62
Module6.ppt
62
RP on a Stick
Header-only Registers
Used to keep (S, G) state alive in the RP Sent every 2 minutes by First-hop router
As long as source is still active Continues sending until a Register-Stop is received
Module6. ppt
63 63
Module6.ppt
63
RP on a Stick
Non-Atomic Join Normal Register (S, G) Join
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: P PT XT Incoming interface: Ethernet0 Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list: Null
rtr-c
E0
192.1.1.1
Member 224.1.1.1
64 64
RP-on-a-Stick Example
In this example, rtr-c is sending Non-Atomic (*, G) Joins to the RP to keep on the Shared Tree. (Note that rtr-c has not joined the SPT at this point. This could be due to the SPT-Threshold being set to Infinity.) The RP is now running version 12.0 or later of IOS. Therefore, when the NonAtomic (*, G) Join for group 224.1.1.1 is received, the RP starts the Proxy Join Timer in all (S, G) entries for group 224.1.1.1. This results in the following state in the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:46, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Notice the X flag is set in the above example. This causes the RP to continue sending (S, G) Joins toward the source (even though the OIL is Null) which, in turn, will keep the traffic flowing to the member across the common Ethernet segment.
Module6.ppt
64
RP on a Stick
Periodic (S, G) Joins Header-only Registers
RP rtr-a
E0 10.1.4.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list:
rtr-c
E0
192.1.1.1
Member 224.1.1.1
65 65
RP-on-a-Stick Example
The First-hop router (rtr-b) is also running version 12.0 or later of IOS and it will therefore send periodic Header-only (S, G) Register messages to the RP. When RP receives these Header-only (S, G) Registers, (roughly every 2 minutes), it resets the Expire timer in the corresponding (S, G) entry in the Mroute table. This results in the following state in the RP: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: (Notice the Expire timer in the (S, G) entry has been reset.)
Module6.ppt
65
Turnaround Router
Module6. ppt
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.
Module6.ppt
66
Turnaround Router
(192.1.1.1, 224.1.1.1) Traffic Flow Shared Tree SPT
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
67 67
Module6.ppt
67
Turnaround Router
Non-Atomic Joins
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
rtr-b
rtr-c
E0
E0
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, Member 00:02:43/00:02:17
Source 192.1.1.1
Module6. ppt
224.1.1.1
68 68
Module6.ppt
68
Turnaround Router
Non-Atomic Joins Normal Register
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
10.1.4.2 E1
10.1.4.3 E1
rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, E0 RP 10.1.3.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17
rtr-c
E0
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Serial0, RPF nbr 10.1.3.2, Source Member Outgoing interface list:
192.1.1.1
224.1.1.1
69 69
Module6.ppt
69
Turnaround Router
Non-Atomic Joins
RP
rtr-a
S0 10.1.3.1
10.1.4.2 E1
10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17
rtr-b
rtr-c
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: T Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list: Serial0, Forward/Sparse, 00:00:48/00:02:12
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
70 70
Module6.ppt
70
Turnaround Router
Non-Atomic Joins
RP
rtr-a
S0 10.1.3.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
71 71
Module6.ppt
71
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1
10.1.4.2 E1
10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, Serial0, RPF nbr nbr 10.1.3.1 10.1.3.1, , Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17
rtr-b
rtr-c
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: Ethernet0, RPF RPF nbr nbr 10.1.4.2, 10.1.4.2, Outgoing interface list: Serial0, Forward/Sparse, 00:00:48/00:02:12
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
72 72
Module6.ppt
72
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.4.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, 10.1.4.2 E1 list: 10.1.4.3 E1 Outgoing interface Serial0, Forward/Sparse, 00:02:43/00:02:17
rtr-b
rtr-c
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT PXT E0 Serial0, RPF nbr 10.1.3.2, E0 Incoming interface: Outgoing interface list:
Source 192.1.1.1
Proxy Join Timer eventually expires (Non-Atomic Joins no longer being received)
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
73 73
Module6.ppt
73
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins (S, G) Prunes (192.1.1.1, 224.1.1.1) Traffic Flow S0 10.1.3.2
RP
rtr-a
S0 10.1.3.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S E0 Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: interface: Ethernet0 Ethernet0, , RPF nbr 10.1.4.2, Outgoing interface list: Source Serial0, Forward/Sparse, 00:00:48/00:02:12 192.1.1.1
rtr-c
E0
Member 224.1.1.1
74 74
Module6.ppt
74
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Join S0 10.1.3.2 (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1
10.1.4.2 E1
10.1.4.3 E1
rtr-b
(*, 224.1.1.1), 00:02:43/00:02:59, E0 RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: P PT XT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Source Outgoing interface list:
rtr-c
E0
Member 224.1.1.1
75 75
Module6.ppt
75
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
10.1.4.2 E1
10.1.4.3 E1
rtr-b
E0 E0
rtr-c
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
76 76
Turnaround Router
Step 11 Finally, Header-only Registers sent by the First-hop router (rtr-b) continue to reset the Expire timer in the (S, G) entry at the RP. This prevents the (S, G) entry from timing out and being deleted at the RP.
Module6.ppt
76
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: 10.1.4.2 E1 Null, RPF nbr 0.0.0.0, 10.1.4.3 E1 Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17
rtr-b
rtr-c
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT E0 Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list:
E0
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
77 77
Turnaround Router
As a result of the Header-only Registers, the state in the RP will be as follows as long as the source and member remain active: (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0, Outgoing interface list: Serial0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PT Incoming interface: Serial0, RPF nbr 10.1.3.2, Outgoing interface list:
Module6.ppt
77
Turnaround Router
Non-Atomic Joins Atomic Joins (S, G) Joins Header-only Registers (192.1.1.1, 224.1.1.1) Traffic Flow
RP
rtr-a
S0 10.1.3.1 S0 10.1.3.2
10.1.4.2 E1
10.1.4.3 E1
(*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: E0 E0 Ethernet0, Forward/Sparse, 00:02:43/00:02:17
rtr-b
rtr-c
(192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list:
Source 192.1.1.1
Module6. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Member 224.1.1.1
78 78
Turnaround Router
As a result of the Non-Atomic Joins, the state in the Turnaround router will be as follows as long as the source and member remain active : (*, 224.1.1.1), 00:02:43/00:02:59, RP 10.1.3.1, flags: S Incoming interface: Serial0, RPF nbr 10.1.3.1, Outgoing interface list: Ethernet0, Forward/Sparse, 00:02:43/00:02:17 (192.1.1.1/32, 224.1.1.1), 00:00:49/00:02:59, flags: PXT Incoming interface: Ethernet0, RPF nbr 10.1.4.2, Outgoing interface list:
Module6.ppt
78
Module6. ppt
79
Module6.ppt
79
Module7. ppt
8/14/2001 10:15 AM
Module7.ppt
Module Objectives
Module7. ppt
2 2
Module7.ppt
Module Agenda
Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast
Module7. ppt
3 3
Module7.ppt
Designed to
Deal with misbehaving sources Sharing bandwidth with unicast traffic
Module7. ppt
4 4
Module7.ppt
Interface-Based Rate-Limiting
Limits total rate of all multicast flows in/out of an interface
Flow-Based Rate-Limiting
Limits rate of each individual (S, G) or (*,G) flow in/out of an interface
Note: Both Interface and FlowFlow -based limits may not be used on an interface at the same time!
Module7. ppt
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
An Interface-based rate limit is defined when the optional Group and/or Source ACLs are not used. A Flow-based rate limit is defined when the optional Group and/or Source ACLs are used
Multiple Flow-based entries may be used per interface Flow-based and Interface -based limits may not be used at the same time
6 6
Module7.ppt
Requirements
Want crystal clear audio Want good response to data actions (interactive) Marginal video acceptable
Configuration
interface serial 0 ip multicast rate-limit out video 48
Router will differentiate UDP port numbers for the same group
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
7 7
Module7.ppt
Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29, Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25, . . .
Total output multicast traffic rate on Serial0 will not exceed 512 Kbps. Kbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8 8
Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output interface-based rate-limits are shown on the entries in the outgoing interface list (OIL) of each mroute table entry. The text following the OIL will have the word Int preceding the rate limit value indicating that this is an Interface-based limit. In the example above, an output interface-based rate-limit of 512kbps has been configured on interface Serial0.
Module7.ppt
Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29 Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25 . . .
Total input multicast traffic rate on Ethernet0 will not exceed 1 Mbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
9 9
Debugging Rate-Limits
Rate-limits may be displayed via the show ip mroute command. Input interfacebased rate-limits are shown on the incoming interface of each mroute table entry. The text following the incoming interface information will have the word Int preceding the rate limit value indicating that this is an Interface-based limit. In the example above, an input interface-based rate-limit of 1 Mbps has been configured on interface Ethernet0.
Module7.ppt
Debugging Rate-Limits
Rtr-A> show ip mroute 224.1.1.1 (*, 224.1.1.1), 7w0d/00:03:29, RP 171.69.10.13, flags: S Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 04:23:22/00:03:25, Int Limit 512 kbps Serial1, Forward/Sparse-Dense, 04:23:28/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 04:23:28/00:02:37, (128.9.160.238, 224.1.1.1), 00:00:48/00:02:42, flags: T Incoming interface: Serial2, RPF nbr 171.68.0.234 Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:48/00:02:41, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:48/00:03:29, Limit 56 kbps Serial3, Forward/Sparse-Dense, 00:00:48/00:03:25, (*, 224.2.2.2), 00:00:38/00:02:51, RP 171.68.20.1, flags: S Incoming interface: Ethernet0, RPF nbr 171.70.100.1, Int Limit 1000 kbps Outgoing interface list: Serial0, Forward/Sparse-Dense, 00:00:38/00:02:51, Int limit 512 kbps Serial1, Forward/Sparse-Dense, 00:00:38/00:03:29 Serial3, Forward/Sparse-Dense, 00:00:38/00:03:25 . . .
Each individual output multicast flow on Serial1 will not exceed 56 Kbps. The total output on Serial1 is the sum of all flows and can exceed 56Kbps.
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
10 10
Debugging Rate-Limits
Rate limits may be displayed via the show ip mroute command. Output flowbased rate-limits are shown on the entries in the outgoing interface list (OIL) of each mroute table entry. The text following the OIL will be missing the word Int preceding the rate limit value. This indicates that this is an flow-based limit. In the example above, an output flow-based rate-limit of 56kbps has been configured on interface Serial1. NOTE: Each individual matching flow will be rate-limited to 56kbps, not the total aggregate of all matching flows. This means that if there are 10 active flows that match the configured flow-based rate-limit, the total aggregate rate out Serial1 could be as high as 560kbps!
Module7.ppt
10
100 Kbps
11 11
Module7.ppt
11
128 Kbps
12 12
Module7.ppt
12
??? Kbps
13 13
Module7.ppt
13
Summary
Flow-based rate-limits do not limit the total aggregate of all the matching flows. Therefore, the use of interfacebased rate-limits are recommended when an upper bound on multicast traffic rates is desired.
Module7. ppt
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.
Module7.ppt
14
High-BW sources use only site-local zone groups Med.-BW, org-wide sources use org.-local zone Low-Med. BW, Internet-wide sources use global zone
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
15 15
Module7.ppt
15
To Internet
Site Local RP/MA
S0
Border A
S0
S1
T1
S0
T1
S0
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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.
Module7.ppt
16
To Internet
Site Local RP/MA
S0
Border A
S0
S1
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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.
Module7.ppt
17
To Internet
Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10
S0
Border A
Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 access-list 10 deny 239.192.0.0 0.0.255.255 access-list 10 permit any
S0
S1
T1
S0
T1
S0
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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.
Module7.ppt
18
To Internet
Site Local RP/MA
S0
Border A
S0
S1
T1
Interface Serial0 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 Interface Serial1 . . . ip multicast ttl-threshold 16 ip multicast boundary 10 Site Local access-list 10 deny 239.192.0.0 0.0.255.255 access-list 10 permit any
T1
S0
S0
Border B
Border C
RP/MA
Site B (LA)
Site C (ATL)
19 19
Module7. ppt
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.
Module7.ppt
19
To Internet
interface Loopback0 Site Local ip address 192.168.10.2 255.255.255.255 RP/MA ip pim send-rp-discovery Loopback0 scope 15 ip pim send-rp-announce Loopback0 scope 15 group 20 access-list 20 permit 239.192.0.0 0.0.255.255
S0
Border A
S0
S1
T1
S0
T1
S0
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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 accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site B as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.
Module7.ppt
20
To Internet
Site Local RP/MA
S0
interface Loopback0 ip address 192.168.10.1 255.255.255.255
Border A
ip pim send-rp-discovery scope 15 ip pim send-rp-announce Loopback0 scope 15 group 20 access-list 20 permit 239.192.0.0 0.0.255.255 S0
S1
T1
S0
T1
S0
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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 accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site C as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.
Module7.ppt
21
To Internet
Site Local RP/MA
S0
Border A
S0
S1
T1
T1
S0
Site B (LA)
Module7. ppt
Site C (ATL)
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 accesscontrol list 20, defines the router as a Candidate RP for the Site-Local group range. Note that a TTL scope of 15 is used on this command so that the Announce messages sourced by this Candidate-RP will not exit the Site. This is accomplished by the use of a ttl-threshold of 16 on Serial0 that was configured in the previous slides.) Note: It is crucial that the Candidate-RP Announce messages do not leak outside of this site and into other sites. If this were to occur, the Mapping Agent(s) in the other site(s) might select the Candidate-RP in Site A as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site.
Module7.ppt
22
To Internet
Site Local RP/MA
S0
Border A
S0
T1
interface Loopback0 S0 ip address 192.168.1.3 Border B255.255.255.255 Border C ip pim send-rp-discovery Loopback0 scope 64 ip pim send-rp-announce Loopback0 scope 64 group 20 ip pim rprp -announce announce-filter rprp -list 10 access accesslist 10 deny 192.168.10.3 Site Local accessaccess -list 10 permit any
S1
T1
RP/MA
access-list 20 permit 224.0.0.0 0.255.255.255 access-list 20 permit 225.0.0.0 0.255.255.255 . . . access-list 20 permit 238.0.0.0 0.255.255.255
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Site B (LA)
Site C (ATL)
23 23
Admin-Scoping Example
Next, an RP for all the non-Site-Local multicast groups must be configured. Border router A has been chosen for this task. Additionally, router A is configured as a Mapping Agent with sufficient scope to cover the entire network. (Note: The independent Mapping Agents for each site make this step unnecessary as they can handle the Mapping Agent functionality for their site.) Once again, interface Loopback0 has been configured for use as the interface of choice for the Mapping Agent and RP. The ip pim send-rp-announce global command along with accesscontrol list 20, defines the router as a Candidate RP for all non-Site-Local groups. Note that a TTL scope of 64 is used on this command so that the Announce messages sourced by this Candidate-RP will reach all routers in all Sites. The ip pim send-rp-discovery global command defines the router as a Mapping Agent for the entire network. Note that a TTL scope of 64 is also used on this command so that the Discovery messages sourced by this Mapping Agent reach all routers in all Sites. Because the scope of the Discovery messages are 64, they will reach all routers in all sites. Therefore, care must be taken to insure that the C-RP information from the Site-Local C-RP in the HQ site is not accepted and inadvertently advertised in Discovery messages by the Mapping Agent. If this were to occur, the routers in the other site(s) might select the Candidate-RP in the HQ Site as the currently active RP for the Site-Local group. This would break Site-Local multicast in that site. To prevent this from happening, the ip pim rp-announce-filter command along with access-control list 10 is used to filter out C-RP Announcement messages from the Site-Local C-RP in the HQ Site. Note: This problem can be avoided if router A is not configured as a Mapping Agent.
Copyright ? ?1998-2001, Cisco Systems, Inc. Module7.ppt 23
To Internet
Site Local RP/MA
S0
Border A
Interface Serial0 . . . S0 ip multicast ttl-threshold 128 ip multicast boundary 10
S1
T1
T1
S0
Border B
Border C
Site B (LA)
Module7. ppt
Site C (ATL)
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
24
Module Agenda
Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast
Module7. ppt
25 25
Module7.ppt
25
Non-Congruent Networks
Module7. ppt
26 26
Module7.ppt
26
Route/Mask, Dist.
(Default Dist. = 0)
(Best Path)
RPF Calculation (Use best Distance unless Longest Match1 is enabled. If enabled, use longest Mask.)
BGP MRIB
Route/Mask, Dist.
(eBGP Def. Dist.=20) (iBGP Def. Dist.=200) (Longest Match)
Route/Mask, Dist.
(Default Dist. = 0)
(Longest Match)
Route/Mask, Dist.
1 Global Command:
ip multicast longest-match
27 27
Module7.ppt
27
Module7. ppt
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.
Module7.ppt
28
Module7. ppt
29 29
Module7.ppt
29
tunnel0
MR UR
Module7. ppt
30 30
Warning!
Care must be used to prevent route redistribution problems
Module7. ppt
31 31
Module7.ppt
31
ip dvmrp unicast-routing
DVMRP Routes*
32 32
Module7.ppt
32
Tunnel
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0
E0
E1
176.32.10.0/24 176.32.15.0/24 Always Use an Access - List with the ip dvmrp metric Command
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
33 33
Module7.ppt
33
Tun 0 E0
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
C
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
34 34
Module7.ppt
34
All Unicast routes are advertised as DVMRP routes as a result of the ip dvmrp metric 1 command.
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
C
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
35 35
Module7.ppt
35
Preferred Route
Module7. ppt
172.16.10.0/24
Tun 0 E0
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
RPF Failure!
Source
1998 2001, Cisco Systems, Inc. All rights reserved.
C
36 36
Module7.ppt
36
Module7. ppt
172.16.10.0/24
Tun 0 E0
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
Source
1998 2001, Cisco Systems, Inc. All rights reserved.
C
37 37
Module7.ppt
37
Only selected Unicast routes are advertised as DVMRP routes as a result of the new acl on the ip dvmrp metric 1 command.
172.16.10.0/24, M=1 172.16.15.0/24, M=1
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
Source
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
C
38 38
Module7.ppt
38
Dist Dist 0 0 0 0
Module7. ppt
172.16.10.0/24
Tun 0 E0
GRE Tunnel
Tun 0 S0
A
E1
S0
B
S1
172.16.15.0/24 172.16.1.0/24
RPF Succeeds!
Source
1998 2001, Cisco Systems, Inc. All rights reserved.
C
39 39
Module7.ppt
39
40 40
Module7.ppt
40
CONCLUSION
Multicast Alternate Path Routing is very complex to implement and administer.
41 41
Module7.ppt
41
Tunneling Capabilities
Tunnels are used when multicast routers dont have contiguous connectivity Support two types of encapsulations for IP multicast traffic
DVMRP tunnels (IP protocol number 4) GRE tunnel (IP protocol number 47)
Module7. ppt
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
42
DVMRP Tunnels
Used between a Cisco router and a non-Cisco DVMRP router DVMRP Tunnel Example
interface tunnel0 tunnel source ethernet0 tunnel destination <ip-address> tunnel mode dvmrp ip unnumbered ethernet0 ip pim sparse-dense
Module7. ppt
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.
Module7.ppt
43
GRE Tunnels
Used between two Cisco routers Looks like a point-to-point link for all protocols in the box,
All packets get an extra IP header Provides data sequencing and security
Used when user wants non-congruent multicast and unicast topologies GRE Tunnel Example
interface tunnel0 tunnel source ethernet0 tunnel destination <ip-address> tunnel mode gre ip ip unnumbered ethernet0 ip pim sparse-dense
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
44 44
GRE Tunnels
When it is necessary to tunnel multicast traffic between two Cisco routers, a GRE Tunnel must be used. The GRE Tunnel appears as a point-to-point link to both ends. Each packet sent down the tunnel gets an extra IP header. GRE tunnels also provide data sequencing and some degree of security. A normal tunnel configuration (such as the one shown above) is used with the tunnel mode set to gre ip.
Module7.ppt
44
When doing MAC level rewrite, select among a set of equal-cost paths to the tunnel endpoint
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
45 45
Module7.ppt
45
SPT Thresholds
SPT thresholds allow you to use both tree typesyou can tailor when you switch from shared to source trees
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
46 46
SPT Thresholds
The key advantage of a Shared Tree is that all multicast flows in the group may use the Shared Tree thereby reducing the amount of multicast forwarding state in the routers in the network. However, the (normally) sub-optimal paths of the Shared Tree introduce additional delay and possible points of congestion along the single common tree. Switching to Sources Trees (aka Shortest-Path Trees or SPT for short) is the default behavior of Ciscos PIM implementation. The advantage of Source Trees is that multicast flows via the shortest path from the sources to the receivers which reduces latency and the potential for congestion. However, this is accomplished at the expense of more multicast forwarding state in the routers in the network. SPT Thresholds permit the network engineer to tune at what point in terms of kbps a last-hop router switches to the SPT.
Module7.ppt
46
SPT Thresholds
Module7. ppt
47 47
SPT Thresholds
SPT Thresholds may be configured on a router using the global configuration command shown above. <kbps> | infinity Defines at what rate in kbps a last-hop router switches to the SPT. If the value of infinity is used the router will never switch to the SPT and traffic will only flow down the Shared Tree. Option ACL that defines the groups for which the SPT-threshold is applicable. If this ACL is not specified, all multicast groups are assumed.
group-list <acl> -
SPT-Thresholds must be configured on each individual router in the network. It will not have the desired affect if it is only configured on the RP. (This is because the RP does not communicate this value to the routers in the network.)
Module7.ppt
47
Module7. ppt
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
48
Problem: hosts take longer than routers to get IP multicast deployed Issue: there are host applications deployed that use UDP broadcast transmission Solution: have routers map broadcast address to multicast address
To make use of IP multicast in the infrastructure as soon as possible
49 49
Module7. ppt
Module7. ppt
50 50
Module7.ppt
50
Broadcast
Multicast A
ip multicast helper-map broadcast 224.1.1.1 100 ttl 15 ip forward-protocol udp 2000 access-list 100 permit any any udp 2000
ACL 100
multicast helper-map
Broadcast
(10.1.1.10, 10.1.1.255) UDP Port 2000
Broadcast
(10.1.1.10, 10.1.1.255) UDP Port 2000
Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000
MATCH!
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
51 51
Module7.ppt
51
Non-Multicast Receiver
.1 E0
Broadcast
ip multicast helper-map 224.1.1.1 10.2.2.255 100 ip forward-protocol udp 2000 access-list 100 permit any any udp 2000
ACL 100
multicast helper-map
Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000
Multicast
(10.1.1.10, 224.1.1.1) UDP Port 2000
Broadcast
(10.1.1.10, 10.2.2.255) UDP Port 2000
MATCH!
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
52 52
Module7.ppt
52
.1 E0
S0
S0
.1 E0
ip multicast helper-map
Interface Ethernet0 ip address 10.1.1.1 255.255.255.0 ip directed-broadcasts ip multicast helper-map broadcast 224.1.1.1 100 ttl 15 access-list 100 permit any any udp 2000 ip forward-protocol udp 2000
Module7. ppt
53 53
Module7.ppt
53
.1 E0
S0
S0
.1 E0
ip multicast helper-map Interface Serial0 ip address 172.16.255.2 255.255.255.252 ip multicast helper-map 224.1.1.1 10.2.2.255 100 ip igmp join-group 224.1.1.1 interface Ethernet0 ip address 10.2.2.1 255.255.255.0 ip directed-broadcast access-list 100 permit any any udp 2000 ip forward-protocol udp 2000
Module7. ppt
54 54
Module7.ppt
54
.1 E0
S0
S0
.1 E0
Broadcast
(10.1.1.10, 10.1.1.255)
Multicast
(10.1.1.10, 224.1.1.1)
Broadcast
(10.1.1.10, 10.2.2.255)
Module7. ppt
55 55
Module7.ppt
55
Module Agenda
Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast
Module7. ppt
56 56
Module7.ppt
56
RP-Failover
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
Module7. ppt
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 RPAnnouncement. 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
57
Tuning RP-Failover
Tune Candidate RPs New interval clause added for C-RPs
ip pim send-rp-announce <intfc> scope <ttl> [group-list acl] [interval <seconds>]
Allows rp-announce-interval to be adjusted Smaller intervals = Faster RP failover Smaller intervals increase amount Auto-RP traffic Increase is usually insignificant Total RP failover time reduced Min. failover ~ 3 seconds
58 58
Module7. ppt
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.
Module7.ppt
58
DR Failover
A
.2 (DR)
192.168.1.0/24
.1
Rtr-B>show ip pim neighbor PIM Neighbor Table Neighbor Address Interface 192.168.1.2 Ethernet0
Uptime 4d22h
Depends on neighbor expiration time Expiration Time sent in PIM query messages
Expiration time = 3 x <query-interval> Default <query-interval> = 30 seconds DR Failover ~ 90 seconds (worst case) by default
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
59 59
Module7.ppt
59
Tuning DR Failover
Module7. ppt
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
60
Unicast routing must converge first PIM converges ~ 5 seconds after unicast PIM convergence algorithm
Entire mroute table scanned every 5 seconds RPF interface recalculated for every (*, G) and (S, G) Joins/prunes/grafts triggered as needed
Module7. ppt
61 61
Module7.ppt
61
Module Agenda
Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast
Module7. ppt
62 62
Module7.ppt
62
A
S0
.2 B
.3 C
.4 D
Module7. ppt
63 63
Module7.ppt
63
A
S0
S0
Module7. ppt
Module7.ppt
64
.1
Layer 3 Viewpoint
192.1.1.0/24
S0 .2
S0 .3
S0
.4
S0 .5
Module7. ppt
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.
Module7.ppt
65
.1
Layer 2 Reality
192.1.1.0/24
S0 .2
S0 .3
S0 .4
S0 .5
Module7. ppt
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.
Module7.ppt
66
.1
Layer 3 Viewpoint
192.1.1.0/24
(*, G) Join S0 .5
S0 .4
Members
Module7. ppt
67 67
Module7.ppt
67
.1
Layer 3 Viewpoint
192.1.1.0/24
S0 .2
S0 .3
S0 .4
S0 .5
Members
Module7. ppt
68 68
Module7.ppt
68
.1
Layer 2 Reality
192.1.1.0/24
Router has to use pseudo broadcast to replicate packets in Layer 2 code Packets go where they are not wanted Process switched!
Unwanted!
S0 .2 S0 .3 S0 .4 S0 .5
Members
Module7. ppt
69 69
Module7.ppt
69
.1
Layer 3 Viewpoint
192.1.1.0/24
(S, G) Prune S0 .2 S0 .3 S0
.4
S0 .5
Members
Module7. ppt
70 70
Module7.ppt
70
.1
Layer 2 Reality
192.1.1.0/24
(S, G) Prune
S0 .2
S0 .3
S0
.4
S0 .5
Members
Module7. ppt
71 71
Module7.ppt
71
.1
Layer 2 Reality
192.1.1.0/24
S0 .2
S0 .3
S0
.4
S0 .5
Module7. ppt
72 72
Module7.ppt
72
NBMA Mode
Solution: PIM-SM + NBMA mode
ip pim nbma-mode
Requires sparse mode When router receives join, it puts the interface and joiner in the outgoing interface list (OIL) When router receives a prune, it removes the interface/joiner from OIL
Module7. ppt
73 73
Module7.ppt
73
NBMA Mode
Avoiding Pseudo Broadcast by Using ip pim nbma-mode
Central Site Router
S0
Interface S0 ip address 192.1.1.1 255.255.255.0 ip pim sparse-dense-mode ip pim nbma-mode
.1
192.1.1.0/24
S0 .2
S0 .3
S0
.4
S0 .5
Module7. ppt
74 74
Module7.ppt
74
NBMA Mode
Avoiding Pseudo Broadcast by Using ip pim nbma-mode
Central Site Router
S0
.1
192.1.1.0/24
(*, G) Join S0 .2
S0 .3
.4
S0 .5
Members
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
75 75
Module7.ppt
75
NBMA Mode
Avoiding Pseudo Broadcast by Using ip pim nbma-mode
Central Site Router
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
Members
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
76 76
Module7.ppt
76
NBMA Mode
Avoiding Pseudo Broadcast by Using ip pim nbma-mode
Central Site Router
Source
E0 S0
.1
192.1.1.0/24
Router can now replicate packets in Layer 3 code Packets only go where needed Fast switched!
S0 .2
S0 .3
S0
.4
S0 .5
Members
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
77 77
Module7.ppt
77
.1
Layer 2 Reality
192.1.1.0/24
Auto-RP Messages
Announce messages Discovery messages
S0
.2 B
S0
.3 C
S0
.4 D
S0
.5 E
C-RP or MA
Module7. ppt
78 78
Module7.ppt
78
A
S0
.1
Layer 2 Reality
192.1.1.0/24
Auto-RP Messages
Announce messages
S0
.2 B
S0
.3 C
S0
.4 D
S0
.5 E
Discovery messages
C-RP
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
79 79
Module7.ppt
79
A
S0
.1
Layer 2 Reality
192.1.1.0/24
S0
.2 B
S0
.3 C
S0
.4 D
S0
.5 E
MA
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
80 80
Module7.ppt
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
81 81
Module7.ppt
81
P2P PVCs
A
ATM
B C
Router Backbone Each PVC is a p2p subinterface Each PVC is a separate subnet ATM fabric modeled as a collection of p2p links to IPmc Use any PIM mode
Module7. ppt
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
82
ATM
B
NBMA Cloud
Each PVC is p2p on a multipoint (sub)interface Router Backbone each router fully meshed to the others ATM fabric modeled as a cloud/subnet Use any PIM mode Pseudo Bcast has poor performance Process-Swiched!!
Module7. ppt
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
83
Each PVC is p2p on a multipoint (sub)interface Router Backbone - each router fully meshed to the others
C
ATM
B
NBMA Cloud
ATM fabric modeled as a cloud/subnet Use PIM sparse mode only with nbma-mode Fast-Switched!!
Module7. ppt
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
84
Module7. ppt
85 85
Module7.ppt
85
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
Module7.ppt
86
Command:
atm multipoint-signaling
Module7. ppt
87 87
An ATM map-list must be configured to specify the IP to ATM NSAP address mapping of all the routers in the ATM LIS. The broadcast keyword must be configured on each entry of the ATM map list. This triggers the router to signal the ATM UNI layer to build a p2mp SVC to these routers in the LIS.
Module7.ppt
87
Module7. ppt
88 88
Module7.ppt
88
One p2mp SVC/group performs multicast replication instead of the router Bcast p2mp SVC used when # Groups > max p2mp VC count Use PIM Sparse mode p2mp SVCs map group membership Fast-Switched!!
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
89
Module7. ppt
90 90
Module7.ppt
90
Commands:
ip pim multipoint-signalling ip pim vc-count <number> ip pim minimum-vc-rate <pps>
Module7. ppt
91 91
Module7.ppt
91
Rate Rate 0 0 pps pps 0 0 pps pps 0 0 pps pps 0 0 pps pps 0 0 pps pps
Module7. ppt
92 92
Module7.ppt
92
93 93
Module7.ppt
93
Module7. ppt
94 94
Module7.ppt
94
95 95
Module7.ppt
95
Module Agenda
Bandwidth Control of Multicast Multicast Traffic Engineering Network Redundancy Multicast over NBMA Networks Reliable Multicast
Module7. ppt
96 96
Module7.ppt
96
IETF draft
draft-speakman-pgm-spec-??.txt
Important point:
Routers dont do the retransmitting
Module7. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
97 97
Module7. ppt
98 98
Module7.ppt
98
N20 N20
N21 N21
N00 N00
N01 N01
R00
Module7. ppt
R01
R02
R03
R04
R05
99 99
Suppresses NAK
1998 2001, Cisco Systems, Inc. All rights reserved.
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.
Module7.ppt
99
N20 N20
N21 N21
Retransmission State
R11
N00 N00
N01 N01
R00
Module7. ppt
R01
R02
R03
R04
R05
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.
Module7.ppt
100
N20 N20
N21 N21
R12 R11
N00 N00
N01 N01
R00
Module7. ppt
R01
R02
R03
R04
R05
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.
Module7.ppt
101
Retransmission State
N20 N20
N21 N21
Retransmission State
N00 N00
N01 N01
R00
Module7. ppt
R01
R02
R03
R04
R05
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.
Module7.ppt
102
Module7.ppt
103
Module7.ppt
103
DVMRP
Module 8
Module8. ppt
8/14/2001 11:24 AM
Module8.ppt
Module Objectives
Explain the basic concepts of DVMRP Identify the various DVMRP Packet types Explain the detailed operation of DVMRP
Module8. ppt
8/14/2001 11:24 AM
2 2
Module8.ppt
Module Agenda
Geekometer
Module8. ppt
8/14/2001 11:24 AM
3 3
Module8.ppt
DVMRP Overview
Distance vector-based
Similar to RIP Infinity = 32 hops Subnet masks in route advertisements
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.
Module8.ppt
DVMRP Overview
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
Module8.ppt
DVMRP Reports
for Multicast Route Exchange
DVMRP Prunes
for pruning multicast delivery trees
DVMRP Grafts
for grafting multicast delivery trees
8/14/2001 11:24 AM
6 6
Module8.ppt
15 Code (0x1)
31
Type (0x13)
Reserved Capabilities
Router is a leaf node Router understands pruning Router sends Generation IDs Router handles Mtrace requests Router handles SNMP requests
8/14/2001 11:24 AM
7 7
Module8.ppt
15
31
Masks: Octets 2-4. Octet 1 = 0xFF (assumed) SrcNets :: Length in octets varies with length of mask. Metrics: (Hops) 1 - 31 = Valid Metric 32 = Infinity (unreachable) 33 - 63 = Poison Reverse
Reserved Mask1 SrcNet11 (cont.)... SrcNet12 (cont.)... Mask2 (cont.) SrcNet 21 (cont.) Mask3 (cont.)
Note: Poison Reverse is used to inform the Parent (uptree) DVMRP Router that we are a Child (down-tree) DVMRP Router and expect to receive traffic from these Source networks via this interface.
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
8 8
Poison Reverse metrics have a special function in DVMRP. When a DVMRP router receives a DVMRP Route Advertisement with a Poison Reverse from one of its DVMRP Neighbors, it indicates that the neighbor is a Child DVMRP Router (I.e. down-tree) which expect to receive multicast traffic from the advertised Source network(s) from this (parent) DVMRP router.
Module8.ppt
Reserved
Module8. ppt
8/14/2001 11:24 AM
9 9
Module8.ppt
Reserved
Reserved
Graft Packet
Module8. ppt
8/14/2001 11:24 AM
10 10
Module8.ppt
10
DVMRP Ask-Neighbors2
request for list of DVMRP Neighbors
(used by mrinfo)
DVMRP Neighbors2
response to above
(used by mrinfo)
Module8. ppt
8/14/2001 11:24 AM
11 11
Module8.ppt
11
Reserved
The Ask -Neighbors2 packet is a unicast request packet directed at a DVMRP router requesting the destination router to respond with a unicast Neighbors2 message back to the sender.
Module8. ppt
8/14/2001 11:24 AM
12 12
Module8.ppt
12
Reserved Capabilites
Local Address1 Metric 1 Threshold1 Nbr1 ... NbrM Local AddressN Metric N ThresholdN Nbr1 ... NbrK
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Local AddressN : IP Address of a local interface. MetricN : Interface Metric ThresholdN : Metric-Threshold Flags N : 0 - Tunnel 1 - Src Route 2 - Reserved 3 - Down 6 - Leaf 4 - Disabled 5 - Reserved
Flags 1
Nbr Cnt1
Flags N
Nbr CntN
Nbr CntN : Number of Neighbors on this interface. NbrX - NbrY : List of Neighbor IP Addresses
8/14/2001 11:24 AM
13 13
Module8.ppt
13
DVMRPBasic Concepts
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
Module8.ppt
14
DVMRPNeighbor Discovery
171.68.37.2 DVMRP Router 2 2 Receives Probe from DVMRP Router 1
mrouted
mrouted
DVMRP Router 1 171.68.37.1
Module8. ppt
8/14/2001 11:24 AM
15 15
Module8.ppt
15
DVMRPBasic Concepts
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
Module8.ppt
16
DVMRPRoute Exchange
Initial State DVMRP Route Table
Network Intf Metric 3 10 151.10.0.0/16 S0 204.1.16.0/24 S0 171.68.37.2 DVMRP Router 2
mrouted
E0
S0
Initial State
E0
mrouted
S0 DVMRP Router 1 171.68.37.1
Module8. ppt
198.14.32.0/24 S0
8/14/2001 11:24 AM
17 17
Module8.ppt
17
DVMRPRoute Exchange
DVMRP Route Table
Network Intf Metric 3 10 151.10.0.0/16 S0 204.1.16.0/24 S0 171.68.37.2 DVMRP Router 2
mrouted
E0
2 E0
mrouted
S0 DVMRP Router 1 171.68.37.1
Module8. ppt
198.14.32.0/24 S0
18 18
Module8.ppt
18
DVMRPRoute Exchange
DVMRP Route Table
Network Intf Metric 3 10 151.10.0.0/16 S0 204.1.16.0/24 S0 171.68.37.2 DVMRP Router 2
mrouted
E0
S0
Poison Reverse
Poison Reverse indicates Router 1 is a Child (Down-Tree) of Router 2 for these Sources
mrouted
S0 DVMRP Router 1 171.68.37.1
Module8. ppt
198.14.32.0/24 S0
8/14/2001 11:24 AM
19 19
Module8.ppt
19
DVMRPRoute Exchange
4 Receives Route Report and adds entry 171.68.37.2 DVMRP Router 2
mrouted
E0
S0
E0
mrouted
S0 DVMRP Router 1 171.68.37.1
Module8. ppt
198.14.32.0/24 S0
20 20
Module8.ppt
20
DVMRPRoute Exchange
171.68.37.2 DVMRP Router 2
mrouted
E0
E0
mrouted
S0 DVMRP Router 1 171.68.37.1
Module8. ppt
Poison Reverse indicates Router 2 is a Child (Down-Tree) of Router 1 for these Sources
198.14.32.0/24 S0
8/14/2001 11:24 AM
21 21
Module8.ppt
21
DVMRPBasic Concepts
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
22
A
mrouted 1 33 1 mrouted 33
B
mrouted 1 2
X
mrouted 3 mrouted 34 35
mrouted 2 2
E
3
35
Y
mrouted
n m
Route for source network of metric n Poison reverse (metric + infinity) sent to upstream parent router. Router depends on parent to receive traffic for this source. Resulting Truncated Broadcast Tree for Source Network
8/14/2001 11:24 AM
Module8. ppt
23 23
Module8.ppt
23
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
8/14/2001 11:24 AM
24 24
Module8.ppt
24
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Source Network S2
Module8. ppt
8/14/2001 11:24 AM
25 25
Advantages of TBTs
The advantage of TBTs is that the initial flooding of multicast traffic throughout the DVMRP network is limited to flowing down the branches of the TBT. This insures that there are no duplicate packets sent as a result of parallel paths in the network.
Disadvantages of TBTs
The disadvantage of using TBTs is that it requires separate DVMRP routing information to be exchanged throughout the entire network. (Unlike other multicast protocols such as PIM that make use of the existing unicast routing table and do not have to exchange additional multicast routing data. Additionally, because DVMRP is based on a RIP model, it has all of the problems associated with a Distance-Vector protocol including, count-to-infinity, holddown, periodic updates. One has to ask oneself, Would I recommend someone build a unicast network based on RIP today? The answer is of course not, protocols like OSPF, IS-IS, and EIGRP have long since superseded RIP in robustness and scalability. The same is true of DVMRP.
Module8.ppt
25
DVMRPBasic Concepts
Neighbor discovery Route exchange Source trees Multicast forwarding Pruning Grafting Tunnels
Module8. ppt
8/14/2001 11:24 AM
26 26
Module8.ppt
26
DVMRPMulticast Forwarding
X
mrouted
S1 S0
mrouted
E0 E1
mrouted
8/14/2001 11:24 AM
27 27
Module8.ppt
27
DVMRPMulticast Forwarding
mrouted
E0 E1
mrouted
8/14/2001 11:24 AM
28 28
Module8.ppt
28
DVMRPMulticast Forwarding
Both B & C have routes to network X. To avoid duplicates, only one router can be Designated Forwarder for network X. Router with best metric is elected as the Designated Forwarder. Lowest IP address used as tie-breaker. Router B wins in this example.
mrouted
mrouted 2 2
8/14/2001 11:24 AM
29 29
Module8.ppt
29
DVMRPBasic Concepts
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
Module8.ppt
30
DVMRP Pruning
Source S Initial Flooding of (S, G) Multicast Packets Down Truncated Broadcast Tree
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
31 31
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.
Module8.ppt
31
DVMRP Pruning
Source S Routers C is a Leaf Node so it sends an (S, G) Prune Message Router B Prunes interface.
A
mrouted Prune
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
32 32
Module8.ppt
32
DVMRP Pruning
Source S Routers X, and Y are also Leaf Nodes so they send Prune (S, G) Messages Router E prunes interface. Prune
A
mrouted
B
mrouted
mrouted
mrouted
mrouted
mrouted
Prune
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
33 33
Module8.ppt
33
DVMRP Pruning
Source S Router E is now a Leaf Node; it sends an (S, G) Prune message. Router D prunes interface.
A
mrouted
B
mrouted
X
mrouted Prune
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
34 34
Module8.ppt
34
DVMRP Pruning
Source S
A
mrouted
B
mrouted
X
mrouted
mrouted
mrouted
mrouted
Y
mrouted
Receiver 1 (Group G)
Truncated Broadcast Tree based on DVMRP route metrics (S, G) Multicast Packet Flow
Module8. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 11:24 AM
35 35
Module8.ppt
35
DVMRPBasic Concepts
Neighbor discovery Route exchange Source trees Multicast forwarding Pruning Grafting Tunnels
Module8. ppt
8/14/2001 11:24 AM
36 36
Module8.ppt
36
DVMRPGrafting
Source S 1 1 Receiver 2 joins Group G Router Y sends a Graft (S, G) Message 1 3 1 mrouted mrouted 1
mrouted
mrouted
X
mrouted
mrouted 1
Graft
E
1
Y
mrouted
Receiver 1 (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.
Receiver 2 (Group G)
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.
Module8.ppt
37
DVMRPGrafting
Source S Router E Responds with a Graft-Ack 1 1
mrouted 3
mrouted
X
mrouted
1 mrouted
Graft mrouted 1
mrouted 1
E
1 GraftGraft - Ack
Y
mrouted
Receiver 1 (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.
Receiver 2 (Group G)
8/14/2001 11:24 AM
38 38
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.
Module8.ppt
38
DVMRPGrafting
Source S Router D Responds with a Graft-Ack 1 1 Begins Forwarding (S, G) Packets
mrouted 3
X
mrouted
mrouted 1
E
1
Y
mrouted
Receiver 1 (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.
Receiver 2 (Group G)
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.
Module8.ppt
39
DVMRPBasic Concepts
Neighbor discovery Route exchange Source trees Multicast forwarding Pruning Grafting Tunnels
Module8. ppt
8/14/2001 11:24 AM
40 40
Module8.ppt
40
DVMRPTunnels
mrouted mrouted
MBONE
mrouted
mrouted
Non-Multicast Network
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.
Module8.ppt
41
DVMRPTunnels
IP in IP Encapsulation
156.23.10.2
mrouted
Dst: 156.23.10.2 Dst: Src: Src : 192.1.1.1 Protocol: 4 Dst: 224.0.1.254 Src: 196.14.23.101 Protocol: xx
Multicast Data
Original Data
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.
Module8.ppt
42
Module8.ppt
43
Module8.ppt
43
Module9.ppt
8/14/2001 2:11 PM
Module9.ppt
Module Objectives Learn that Cisco routers dont run DVMRP! Explain Cisco routers PIM-DVMRP interoperability features & functions. Demonstrate an ability to configure PIM-DVMRP interoperability Demonstrate an ability to debug PIM-DVMRP interoperability
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
Module9.ppt
Module Agenda
Geekometer
Module9.ppt
8/14/2001 2:11 PM
Module9.ppt
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
Module9.ppt
mrouted
DVMRP Probe
10.1.1.0/24
E0
Router A E1 176.32.10.0/24
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Whoa! Theres a DVMRP router on this PIM interface! Ill turn on DVMRP interoperation.
8/14/2001 2:11 PM
Module9.ppt
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
Module9.ppt
DVMRP Tunnel w/Poison Reverse Tunnel0 DVMRP Route Table Unicast Route Table DVMRP Reports*
E0 PIM Network
8/14/2001 2:11 PM
Module9.ppt
DVMRP Grafts
DVMRP Reports* E1 Ignored Ignored E0 * Unicast routes advertised depends on several factors ** IGMP group joins sent for all known groups in PIM cloud
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
PIM Network
8/14/2001 2:11 PM 8
Module9.ppt
PIM-DVMRP Interaction
Problem with old Default PM-DVMRP interaction over non-p2p links (prior to 11.2(13))
mrouted
Source S, Group G
RP Border Router Router A Mcst Cache Empty Router B Mcst Cache (*,G) Router C Mcst Cache (*,G) Receiver, Group G PIM-Sparse Mode
Border router doesnt know about group G and doesnt send an IGMP group join for G Therefore, DVMRP router will not forward packets from source S
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
Module9.ppt
DVMRP Grafts
w/Poison Reverse E1 Ignored DVMRP Route Table *Unicast routes advertised depends on several factors. **IGMP Group Joins discontinued.
Module9.ppt
DVMRP Reports* DVMRP DVMRP Prunes Grafts Unicast Route Table IGMP Group Joins**
E0 PIM Network
8/14/2001 2:11 PM
10 10
Module9.ppt
10
PIM-DVMRP Interaction
Using ip dvmrp unicast-routing over non-p2p links (prior to version 11.2(13))
mrouted
Source S, Group G
Border router now sends poison reverse routes so DVMRP router knows to forward packets from S
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
11 11
Module9.ppt
11
DVMRP Grafts
w/Poison Reverse E1 Ignored DVMRP Route * ip dvmrp unicast-routingTable no longer necessary. ** Unicast routes advertised depends on several factors.
Module9.ppt
E0 PIM Network
8/14/2001 2:11 PM
12 12
Module9.ppt
12
mrouted
Prune (S, G)
(S, G) Traffic Im not keeping track of each DVMRP neighbor. So I dont know if they have ALL sent a Prune or not??!! Network S
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Ignored
8/14/2001 2:11 PM
13 13
Module9.ppt
13
mrouted
Unwanted Traffic!!!
Normal Routes
Si , Sj , Sk Traffic
Ignored
Module9.ppt
Module9.ppt
14
DVMRP Grafts
DVMRP Prunes
w/Poison Reverse E1
DVMRP Route Table * DVMRP neighbors tracked. DVMRP Prunes supported. ** Unicast routes advertised depends on several factors.
Module9.ppt
E0 PIM Network
8/14/2001 2:11 PM
15 15
Module9.ppt
15
PIM-DVMRP Interaction
Recommendations
Use IOS release 12.1 or later. OR Use DVMRP tunnels or p2p interfaces whenever possible.
Module9.ppt
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
16
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
17 17
Module9.ppt
17
mrouted
Tunnel
DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0 Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
E0
E1
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
Module9.ppt
18
mrouted
Tunnel
ip unnumbered Ethernet 0 ... interface E0 ip addr 176.32.10.1 255.255.255.0 ip pim dense-mode interface E1 ip addr 176.32.15.1 255.255.255.0 ip pim dense-mode
DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0
E0
E1
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
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
The Cisco router Poison-Reverses these routes by adding Infinity (32) to these metrics and sending them back to the DVMRP router. This informs the DVMRP router that the Cisco router should be included on the Truncated Broadcast Tree for these source networks. This will cause traffic from any source in these networks to be flooded across the interface. The Cisco router is automatically redistributing (advertising) all connected routes from its unicast route table with a DVMRP metric of one. This results in the following DVMRP route advertisements being sent to the DVMRP neighbor: 176.32.10.0/24 176.32.15.0/24 Metric=1 Metric=1
Module9.ppt
19
mrouted
Tunnel 204.10.10.0/24
DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0
E0
E1
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
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
Module9.ppt
20
mrouted
Tunnel
DVMRP Route Table Src Network Intf Metric Dist 151.16.0.0/16 E0 7 0 172.34.15.0/24 E0 10 0 202.13.3.0/24 E0 8 0
E0
E1
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
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
Module9.ppt
21
mrouted
Tunnel
E0
E1
Unicast Route Table (10,000 Routes) Network Intf Metric Dist 176.32.10.0/24 E0 10514432 90 176.32.15.0/24 E1 10512012 90 176.32.20.0/24 E1 45106272 90 (Includes 200-176.32 Routes)
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
22
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
23 23
Module9.ppt
23
8/14/2001 2:11 PM
24 24
Module9.ppt
24
Route/Mask, Dist.
(Default Dist. = 0)
(Best Path)
RPF Calculation (Use best Distance unless Longest Match1 is enabled. If enabled, use longest Mask.)
BGP MRIB
Route/Mask, Dist.
(eBGP Def. Dist.=20) (iBGP Def. Dist.=200) (Longest Match)
Route/Mask, Dist.
(Default Dist. = 0)
(Longest Match)
Route/Mask, Dist.
1 Global Command:
ip multicast longest-match
8/14/2001 2:11 PM 25 25
Module9.ppt
25
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
26 26
Module9.ppt
26
PIM-DVMRP Congruency
Module9.ppt
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.
Module9.ppt
27
PIM/DVMRP Congruency
DVMRP
Physical Path Tunnel Path Data Flow RPF Path
PIM-DM
MR1 Packets not forwarded !!! Receiver Receiver RPF Failure !!!
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
MR2
8/14/2001 2:11 PM
28 28
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
28
PIM/DVMRP Congruency
Module9.ppt
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.
Module9.ppt
29
PIM/DVMRP Congruency
DVMRP
Congruent Topologies
Physical Path Tunnel Path Data Flow RPF Path
MR3
PIM-DM
MR1
MR2
Receiver
Receiver
Module9.ppt
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.
Module9.ppt
30
PIM/DVMRP Congruency
DVMRP
MR3
PIM-DM
MR2: interface tunnel0 ip unnumbered ethernet0 ip pim dense-mode tunnel mode dvmrp tunnel source ethernet0 tunnel destination <mrouted> interface Serial0 ip pim dense-mode ip dvmrp unicast-routing
MR1
S0 S0
MR2
Receiver
Module9.ppt
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.
Module9.ppt
31
ip dvmrp unicast-routing
DVMRP Reports*
PIM Router *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
Module9.ppt
32
RPF Direction
X X
RPF Failures!!!
Mcst Traffic
Module9.ppt
8/14/2001 2:11 PM
33 33
Module9.ppt
33
Module9.ppt
8/14/2001 2:11 PM
34 34
Module9.ppt
34
DVMRP route exchange must be enabled from here up in the hierarchy!! hierarchy!!
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
35 35
Module9.ppt
35
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
36 36
Module9.ppt
36
8/14/2001 2:11 PM
37 37
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
37
PIM-DM/DVMRP Boundaries
Perform normal RPF check If passed, flood out all (S,G) OIL entries
Observing any Pruned (S,G) OIL state
Module9.ppt
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
38
Perform normal RPF check. If passed then Flood out all (S,G) OIL entries.
Observing any Pruned (S,G) OIL state
(Above behavior assumes latest IOS code.)
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
39
PIM-DVMRP Interoperability DVMRP router discovery Basic PIM-DVMRP interaction PIM-DVMRP route exchange PIM-DVMRP RPF checking PIM-DVMRP congruency PIM-DM/DVMRP Boundaries PIM-SM/DVMRP Boundaries
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
40 40
Module9.ppt
40
Module9.ppt
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 PIMDM/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
41
PIM-SM/DVMRP Boundaries
Proxy-Register initial (S,G) packets with RP. Join Shared-Tree for group G. Operate using normal PIM-SM forwarding rules.
Module9.ppt
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
42
PIM-SM/DVMRP Boundaries
Module9.ppt
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-aSender 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.
Module9.ppt
43
PIM-Sparse Mode
Border router is unaware of Recv-Only Host in DVMRP cloud and therefore has no state for Group G. (S1 , G) Traffic doesnt make it to Border router nor DVMRP Cloud.
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
44 44
Module9.ppt
44
PIM-Sparse Mode
Module9.ppt
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.
Module9.ppt
45
Border Router
PIM-Sparse Mode
Need to minimize distance between Border & RP to keep Dense-mode cloud small. Requires carefully planning of topology.
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
46 46
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.
Module9.ppt
46
PIM-Sparse Mode
Works fine for most Mbone applications since they both send and receive. Not applicable for applications that are Rcv-Only.
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
47 47
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.
Module9.ppt
47
Module Agenda
Module9.ppt
8/14/2001 2:11 PM
48 48
Module9.ppt
48
Route Redistribution
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: ip dvmrp metric <metric> [list <acl>] [<protocol> | dvmrp] [route-map <map>] This command can be used multiple times on an interface. The <metric> field is in hops and is normally set to a value of 1. A metric of 0 has a special meaning which means any matching routers are not to be advertised. Either ACLs or Route-Maps may be used to match the desired routes in the Unicast routing table that are to be advertised. If the <protocol><process-id> is configured, only routes learned by the specified routing protocol will be advertised in DVMRP Report messages. This parameter can be used in conjunction with <access-list> so a selective list of destinations learned from a given routing protocol may be reported. If this command is not used, only directly connected networks are advertised when DVMRP neighbors are discovered. If the "dvmrp" keyword is configured, only routes from the DVMRP routing table will be selected to be advertised with <metric>. Warning: Care should be used when configuring this command as it is easy to configure route loops whenever route redistribution is used.
Module9.ppt
49
Route Redistribution
Preventing redistribution of DVMRP routes back into DVMRP cloud to avoid being transit network.
DVMRP Cloud
mrouted mrouted
Module9.ppt
8/14/2001 2:11 PM
50 50
Module9.ppt
50
Route Redistribution
You can specify what you want to receive:
ip dvmrp accept-filter <acl> [<distance>]
Note: DVMRP Probes are ignored from DVMRP neighbors that are denied in the neighbor-list <acl>.
This can be used to disable automatic PIM-DVMRP interoperability on an interface.
Module9.ppt
8/14/2001 2:11 PM
51 51
Module9.ppt
51
Route Redistribution
Defaults: delay = 100ms; burst = 2 Added IOS 11.2(9) Prior releases: delay = 0; burst = infinity
Module9.ppt
8/14/2001 2:11 PM
52 52
Module9.ppt
52
You can originate the DVMRP default route with other routes
ip dvmrp default-information originate
Module9.ppt
8/14/2001 2:11 PM
53 53
Module9.ppt
53
Summary Origination
Classful summarization is on by default
As long as the subnets are from a different network number than the network number of the interface the advertisement is being sent out on
Module9.ppt
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
54
Summary Origination
Module9.ppt
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. Multiple summary addresses can be configured on an interface. When multiple overlapping summary addresses are configured on an interface, the one with the longest mask takes preference. (This command was first introduced in IOS version 11.2.)
Module9.ppt
55
Module9.ppt
8/14/2001 2:11 PM
56 56
Module9.ppt
56
Module Agenda
Module9.ppt
8/14/2001 2:11 PM
57 57
Module9.ppt
57
Debugging Tips
Example Network
DVMRP network
pim-dvmrp-gw:
mrouted
interface tunnel0 ip unnumbered ethernet0 ip pim dense-mode tunnel mode dvmrp tunnel source ethernet0 tunnel destination 135.1.22.98 interface ethernet0 ip addr 135.1.3.102 255.255.255.0 ip pim dense-mode interface ethernet1 ip addr 135.1.2.102 255.255.255.0 ip pim dense-mode
135.1.2.100
Module9.ppt
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
58
Debugging Tips
Verifying the DVMRP tunnel Verifying DVMRP route exchange Verifying Multicast reception Verifying Multicast transmission
Module9.ppt
8/14/2001 2:11 PM
59 59
Module9.ppt
59
Module9.ppt
Module9.ppt
60
Module9.ppt
8/14/2001 2:11 PM
61 61
61
Debugging Tips
Verifying the DVMRP tunnel Verifying DVMRP route exchange Verifying Multicast reception Verifying Multicast transmission
Module9.ppt
8/14/2001 2:11 PM
62 62
Module9.ppt
62
Verifying DVMRP Route Exchange Using the show ip dvmrp route Command
pim -dvmrp pimdvmrp-gw gw# # show ip dvmrp route DVMRP Routing Table - 8 entries 130.1.0.0/16 [0/3] uptime 00:19:03, expires 00:02:13 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 135.1.0.0/16 [0/3] uptime 00:19:03, expires 00:02:13 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 135.1.22.0/24 [0/2] uptime 00:19:03, expires 00:02:13 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 171.69.0.0/16 [0/3] uptime 00:19:03, expires 00:02:13 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 172.21.27.0/24 [0/3] uptime 00:19:04, expires 00:02:12 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 172.21.32.0/24 [0/2] uptime 00:19:04, expires 00:02:12 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 172.21.33.0/24 [0/3] uptime 00:19:04, expires 00:02:12 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM] 172.21.120.0/24 [0/3] uptime 00:19:04, expires 00:02:12 via 135.1.22.98, Tunnel0, [version mrouted 3.8] [flags: GPM]
Module9.ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 2:11 PM
63 63
Module9.ppt
63
Module9.ppt
8/14/2001 2:11 PM
64 64
Module9.ppt
64
8/14/2001 2:11 PM
65 65
Module9.ppt
65
Module9.ppt
8/14/2001 2:11 PM
66 66
Module9.ppt
66
Debugging Tips
Verifying the DVMRP tunnel Verifying DVMRP route exchange Verifying Multicast reception Verifying Multicast transmission
Module9.ppt
8/14/2001 2:11 PM
67 67
Module9.ppt
67
8/14/2001 2:11 PM
68 68
Module9.ppt
68
8/14/2001 2:11 PM
69 69
Module9.ppt
69
8/14/2001 2:11 PM
70 70
Module9.ppt
70
Debugging Tips
Verifying the DVMRP tunnel Verifying DVMRP route exchange Verifying Multicast reception Verifying Multicast transmission
Module9.ppt
8/14/2001 2:11 PM
71 71
Module9.ppt
71
Module9.ppt
8/14/2001 2:11 PM
72 72
Module9.ppt
72
Module9.ppt
8/14/2001 2:11 PM
73 73
Module9.ppt
73
Module9.ppt
74 74
Module9.ppt
74
Module10. ppt
8/14/2001 3:35 PM
Module10.ppt
Module Objectives
Understand the basic concepts of BGP Explain the MBGP extensions to BGP Identify steps associated with configuring and debugging MBGP
Module10. ppt
8/14/2001 3:35 PM
2 2
Module10.ppt
Agenda
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
Routing Protocol used between ASs Currently Version 4 Runs over TCP Path Vector Protocol Incremental Updates
Module10. ppt
8/14/2001 3:35 PM
4 4
Module10.ppt
BGP Peers
A C
AS 100
220.220.8.0/24
AS 101
220.220.16.0/24
BGP speakers are called peers Peers in different ASs are called External Peers
eBGP TCP/IP Peer Connection
AS 102
220.220.32.0/24
8/14/2001 3:35 PM
5 5
Module10.ppt
BGP Peers
A C
AS 100
220.220.8.0/24
AS 101
220.220.16.0/24
BGP speakers are called peers Peers in the same AS are called Internal Peers
iBGP TCP/IP Peer Connection
Module10. ppt
AS 102
220.220.32.0/24
6 6
Module10.ppt
BGP Peers
A C
AS 100
220.220.8.0/24
AS 101
220.220.16.0/24
BGP Peers exchange Update messages containing Network Layer Reachability Information (NLRI)
BGP Update Messages
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
AS 102
220.220.32.0/24
8/14/2001 3:35 PM
7 7
Module10.ppt
AS 101
C
.2
222.222.10.0/30
220.220.8.0/24
.1
.2
.1
220.220.16.0/24
.1
interface Serial 0 ip address 222.222.10.2 255.255.255.252 router bgp 100 network 220.220.8.0 mask 255.255.255.0 neighbor 222.222.10.1 remoteremote-as 101
interface Serial 0 ip address 222.222.10.1 255.255.255.252 router bgp 101 network 220.220.16.0 mask 255.255.255.0 neighbor 222.222.10.2 remoteremote-as 100
BGP Peering sessions are established using the BGP neighbor configuration command
External (eBGP) is configured when AS numbers are different
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
8 8
Module10.ppt
AS 101
iBGP TCP Connection .1
.2
220.220.8.0/24
.2
.1
.2
220.220.16.0/24
.1
interface Serial 1 ip address 220.220.16.2 255.255.255.252 router bgp 101 network 220.220.16.0 mask 255.255.255.0 neighbor 220.220.16.1 remoteremote-as 101
interface Serial 1 ip address 222.220.16.1 255.255.255.252 router bgp 101 network 220.220.16.0 mask 255.255.255.0 neighbor 220.220.16.2 remoteremote-as 101
BGP Peering sessions are established using the BGP neighbor configuration command
External (eBGP) is configured when AS numbers are different Internal (iBGP) is configured when AS numbers are same
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
9 9
Module10.ppt
Each iBGP speaker must peer with every other iBGP speaker in the AS
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
10 10
Module10.ppt
10
215.10.7.1
215.10.7.3
8/14/2001 3:35 PM
11 11
Module10.ppt
11
215.10.7.1
215.10.7.3
C
remote-as 100 update-source loopback0 updateremote-as 100 update-source loopback0 update-
Module10. ppt
8/14/2001 3:35 PM
12 12
Module10.ppt
12
215.10.7.1
215.10.7.3
interface loopback 0 ip address 215.10.7.2 255.255.255.255 router bgp 100 network 220.220.5.0 neighbor 215.10.7.1 neighbor 215.10.7.1 neighbor 215.10.7.3 neighbor 215.10.7.3
Module10. ppt
8/14/2001 3:35 PM
13 13
Module10.ppt
13
215.10.7.1
215.10.7.3
remote-as 100 update-source loopback0 updateremote-as 100 update-source loopback0 update8/14/2001 3:35 PM
14 14
Module10.ppt
14
A BGP update is used to advertise a single feasible route to a peer, or to withdraw multiple unfeasible routes Each update message contains attributes, like origin, ASPath, Next-Hop, .
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
15 15
Module10.ppt
15
Network Layer Reachability Information Used to advertise feasible routes Composed of:
Network Prefix Mask Length
Module10. ppt
8/14/2001 3:35 PM
16 16
Module10.ppt
16
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.
Module10.ppt
17
AS-Path Attribute
Sequence of ASes a route has traversed Loop detection Apply policy AS 300
AS 200
170.10.0.0/16
AS 100
180.10.0.0/16
AS 400
150.10.0.0/16 Network 180.10.0.0/16 170.10.0.0/16 150.10.0.0/16 Path 300 200 100 300 200 300 400
AS 500
Module10. ppt
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.
Module10.ppt
18
192.10.1.0/30
140.10.0.0/16
.2
.1
D E
.2
Path 100
.1
Next hop to reach a network Usually a local network is the next hop in eBGP session
AS 100
160.10.0.0/16
Module10. ppt
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.
Module10.ppt
19
192.10.1.0/30
140.10.0.0/16
.2
.1
D E
.2
.1
Next hop to reach a network Usually a local network is the next hop in eBGP session Next Hop updated between eBGP Peers
8/14/2001 3:35 PM
AS 100
160.10.0.0/16
Module10. ppt
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.
Module10.ppt
20
192.10.1.0/30
140.10.0.0/16
.2
.1
D E
.2
.1
AS 100
160.10.0.0/16
Module10. ppt
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
21
IGP should carry route to next hops Recursive route look-up Unlinks BGP from actual physical topology Allows IGP to make intelligent forwarding decision
Module10. ppt
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
22
Module10. ppt
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.
Module10.ppt
23
AS 321
BGP Update Message
Connectivity lost
192.192.25.0/24
Network Next-Hop Path 150.10.0.0/16 192.168.10.2 321 200 192.192.25.0/24 192.168.10.2 321
Module10. ppt
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
24
router bgp 100 network 160.10.1.0 255.255.255.0 network 160.10.3.0 255.255.255.0 no auto-summary
D D D R S 10.1.2.0/24 160.10.1.0/24 160.10.3.0/24 153.22.0.0/16 192.1.1.0/24
Route Table
BGP network commands are normally used to populate the BGP RIB with routes from the Route Table
Module10. ppt
8/14/2001 3:35 PM
25 25
Module10.ppt
25
router bgp 100 network 160.10.1.0 255.255.255.0 network 160.10.3.0 255.255.255.0 aggregate-address 160.10.0.0 255.255.0.0 summary-only no auto-summary
D D D R S 10.1.2.0/24 160.10.1.0/24 160.10.3.0/24 153.22.0.0/16 192.1.1.0/24
Route Table
BGP aggregate -address commands may be used to install summary routes in the BGP RIB
Module10. ppt
8/14/2001 3:35 PM
26 26
Module10.ppt
26
router bgp 100 network 160.10.0.0 255.255.0.0 redistribute static route-map foo no auto-summary
D D D R S 10.1.2.0/24 160.10.1.0/24 160.10.3.0/24 153.22.0.0/16 192.1.1.0/24
Route Table
BGP redistribute commands can also be used to populate the BGP RIB with routes from the Route Table
Module10. ppt
8/14/2001 3:35 PM
27 27
Module10.ppt
27
OUT Process
Update
Update
Path 100
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
Module10.ppt
28
OUT Process
Update
Update
Path Path 200 200 200 200 200 200 100 100
Next-Hop changed
8/14/2001 3:35 PM
29 29
Module10.ppt
29
D D D R S B
Route Table
Module10. ppt 8/14/2001 3:35 PM
30 30
Module10.ppt
30
MBGPMultiprotocol BGP
MBGP Overview MBGP Update Messages MBGP Capability Negotiation MBGP NLRI exchange MBGP-DVMRP redistribution BGP-to-MBGP redistribution
Module10. ppt
8/14/2001 3:35 PM
31 31
Module10.ppt
31
MBGP Overview
MBGP: Multiprotocol BGP Defined in RFC 2283 (extensions to BGP) Can carry different types of routes
IPv4 Unicast IPv4 Multicast IPv6 Unicast
May be carried in same BGP session Does not propagate multicast state info
Still need PIM to build Distribution Trees
8/14/2001 3:35 PM
32 32
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
32
MBGP Overview
Separate BGP tables maintained
Unicast Routing Information Base (U -RIB) Multicast Routing Information Base (M-RIB) New BGP nlri keyword specifies which RIB Allows different unicast/multicast topologies or policies
8/14/2001 3:35 PM
33 33
Module10.ppt
33
MBGP Overview
NLRI capability negotiation Redistribution between MBGP and DVMRP Redistribution of BGP stubs into MBGP
Module10. ppt
8/14/2001 3:35 PM
34 34
Module10.ppt
34
35 35
Module10.ppt
35
RFC 1700
May be Zero
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
36
Module10. ppt
8/14/2001 3:35 PM
37 37
Module10.ppt
37
MP_UNREACH_NLRI Attribute
Address Family Identifier (2 Octets) Subsequent Address Family Identifier (1 Octet) Withdrawn Routes (Variable) Length (I Octet) Prefix (Variable)
Module10. ppt
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
38
MBGPCapability Negotiation
BGP routers establish BGP sessions through the OPEN message OPEN message contains optional parameters BGP session is terminated if OPEN parameters are not recognised New parameter: CAPABILITIES
Multiprotocol extension Multiple routes for same destination
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
39 39
Module10.ppt
39
MBGPCapability Negotiation
Configures router to negotiate either or both types of NLRI If neighbor configures both or subset, common NRLI is used in both directions If there is no match, notification is sent and peering doesnt come up
Module10. ppt
8/14/2001 3:35 PM
40 40
If foo has configured the same set of abilities, then both unicast and multicast NLRI can be exchanged via the session. If the two peers do not match, the lowest common subset is used. If there is no match between the capabilities, the peering will not come up.
Module10.ppt
40
AS 321
router bgp 123 neighbor 192.168.100.2 remote-as 321 nlri unicast multicast . . .
Receiver
Sender
Module10. ppt
8/14/2001 3:35 PM
41 41
Module10.ppt
41
AS 321
router bgp 321 neighbor 192.168.100.1 remote-as 123 nlri unicast multicast . . .
Receiver
Sender
Module10. ppt
8/14/2001 3:35 PM
42 42
instructs the router on the right to attempt to negotiate both unicast and multicast NLRI exchange.
Module10.ppt
42
AS 321
Receiver
BGP: BGP: BGP: BGP: BGP: BGP: BGP: BGP: BGP: BGP: BGP: BGP:
192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2 192.168.100.2
open active, local address 192.168.100.1 went from Active to OpenSent sending OPEN, version 4 192.192.25.0/24 OPEN rcvd, version 4 rcv OPEN w/option parameter type: 2, len: 6 OPEN has CAPABILITY code: 1, length 4 Sender OPEN has MP_EXT CAP for afi/safi: 1/1 rcv OPEN w/option parameter type: 2, len: 6 OPEN has CAPABILITY code: 1, length 4 OPEN has MP_EXT CAP for afi/safi: 1/2 went from OpenSent to OpenConfirm went from OpenConfirm to Established
Module10. ppt
8/14/2001 3:35 PM
43 43
Module10.ppt
43
If neighbor doesnt include the CAPABILITY parameters in open, Cisco backs off and reopens with no capability parameters Peering comes up in unicast-only mode Hidden command
neighbor <foo> dont-capability-negotiate
Module10. ppt
8/14/2001 3:35 PM
44 44
Module10.ppt
44
New nlri keyword controls in which RIB the matching route(s) is(are) stored M-RIB if multicast keyword specified U-RIB if unicast keyword specified (or if nlri clause omitted) Both RIBs if both keywords specified
Module10. ppt
8/14/2001 3:35 PM
45 45
Module10.ppt
45
Multicast RIB
Network Next-Hop Path
D D D R S
router bgp 100 network 160.10.1.0 255.255.255.0 nlri unicast network 160.10.3.0 255.255.255.0 nlri unicast no auto-summary
New nlri keyword used to control RIB population. (e.g. network command)
Unicast RIB only
Route Table
Module10. ppt
8/14/2001 3:35 PM
46 46
Module10.ppt
46
Multicast RIB
Network *>i160.10.1.0/24 *>i160.10.3.0/24 Next-Hop 192.20.2.2 192.20.2.2 Path i i
D D D R S
router bgp 100 network 160.10.1.0 255.255.255.0 nlri multicast network 160.10.3.0 255.255.255.0 nlri multicast no auto-summary
New nlri keyword used to control RIB population. (e.g. network command)
Unicast RIB only Multicast RIB only
Route Table
Module10. ppt
8/14/2001 3:35 PM
47 47
Module10.ppt
47
Multicast RIB
Network *>i160.10.1.0/24 *>i160.10.3.0/24 Next-Hop 192.20.2.2 192.20.2.2 Path i i
D D D R S
router bgp 100 network 160.10.1.0 255.255.255.0 nlri unicast multicast network 160.10.3.0 255.255.255.0 nlri unicast multicast no auto-summary
New nlri keyword used to control RIB population. (e.g. network command)
Unicast RIB only Multicast RIB only Both RIBs
8/14/2001 3:35 PM
Route Table
Module10. ppt
48 48
Module10.ppt
48
Route map set nlri clause controls which RIB the matching route(s) is(are) stored
Module10. ppt
8/14/2001 3:35 PM
49 49
Module10.ppt
49
Multicast RIB
Network *>i192.1.1.0/24 Next-Hop 192.20.2.2 Path ?
router bgp 100 redistribute static route-map foo access-list 1 permit 192.1.1.0 0.0.0.255
D D D R S 10.1.2.0/24 160.10.1.0/24 160.10.3.0/24 153.22.0.0/16 192.1.1.0/24
Route Table
Module10. ppt
8/14/2001 3:35 PM
Module10.ppt
50
Default Origination
neighbor <foo> default-originate [nlri multicast unicast]
In Route Maps
match nlri multicast unicast
Injects the matched route into the specified unicast or multicast RIB
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
51 51
Module10.ppt
51
Module10. ppt
8/14/2001 3:35 PM
52 52
Module10.ppt
52
Multicast RIB
Network *>i160.10.1.0/24 *>i160.10.3.0/24 Next-Hop 192.20.2.2 192.20.2.2 Path i i
Storage of arriving NLRI information depends on AFI/SAFI fields in the Update message Unicast RIB only (AFI=1/SAFI=1 or old style NLRI)
Module10. ppt
8/14/2001 3:35 PM
53 53
Module10.ppt
53
Multicast RIB
Network *>i160.10.1.0/24 *>i160.10.3.0/24 *>i192.192.2.0/24 Next-Hop 192.20.2.2 192.20.2.2 192.168.200.2 Path i i 300 200 i
Storage of arriving NLRI information depends on AFI/SAFI fields in the Update message Unicast RIB only (AFI=1/SAFI=1 or old style NLRI) Multicast RIB only (AFI=1/SAFI=2)
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
54 54
Module10.ppt
54
Multicast RIB
Network *>i160.10.1.0/24 *>i160.10.3.0/24 *>i192.192.2.0/24 Next-Hop 192.20.2.2 192.20.2.2 192.168.200.2 Path i i 300 200 i
Storage of arriving NLRI information depends on AFI/SAFI fields in the Update message Unicast RIB only (AFI=1/SAFI=1 or old style NLRI) Multicast RIB only (AFI=1/SAFI=2) Both RIBs (AFI=1/SAFI=3)
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
55 55
Module10.ppt
55
Congruent Topologies
AS 123
.1
AS 321
192.168.10.0/24
router bgp 123 neighbor 192.168.100.2 remote-as 321 nlri unicast multicast network 192.168.10.0 255.255.255.0 nlri unicast multicast no auto-summary
192.192.25.0/24
Receiver
Sender
Module10. ppt
8/14/2001 3:35 PM
56 56
Module10.ppt
56
Congruent Topologies
AS 123
.1
AS 321
192.168.10.0/24
router bgp 321 neighbor 192.168.100.1 remote-as 123 nlri unicast multicast network 192.192.25.0 255.255.255.0 nlri unicast multicast no auto-summary
192.192.25.0/24
Receiver
Sender
Module10. ppt
8/14/2001 3:35 PM
57 57
Module10.ppt
57
Congruent Topologies
AS 123
.1
AS 321
Unicast Information NLRI: 192.192.25/24 AS_PATH: 321 MED: Next-Hop: 192.168.100.2 ... 192.192.25.0/24 Multicast Information Receiver MP_REACH_NLRI: 192.192.25/24 AFI: 1, Sub-AFI: 2 (multicast) AS_PATH: 321 MED: Next-Hop: 192.168.100.2 ... Routing Update
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
192.168.10.0/24
Sender
8/14/2001 3:35 PM
58 58
Module10.ppt
58
Congruent Topologies
AS 123
.1
AS 321
Unicast Information NLRI: 192.168.10/24 AS_PATH: 123 MED: Next-Hop: 192.168.100.1 ... Multicast Information Receiver MP_REACH_NLRI: 192.168.10/24 AFI: 1, Sub-AFI: 2 (multicast) AS_PATH: 123 MED: Next-Hop: 192.168.100.1 ... Routing Update
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
192.168.10.0/24
192.192.25.0/24
Sender
8/14/2001 3:35 PM
59 59
Module10.ppt
59
Incongruent Topologies
AS 123 AS 321 .1 .1 Unicast Traffic 192.168.100.0/24 .2
192.168.10.0/24 router bgp 321 . . . network 192.192.25.0 255.255.255.0 nlri unicast multicast neighbor 192.168.100.1 remote-as 123 nlri unicast neighbor 192.168.200.1 remote-as 123 nlri multicast
Sender
Module10. ppt
8/14/2001 3:35 PM
60 60
The first command instructs the router on the right to negotiate a unicastonly BGP session over the top serial link while the second command instructs it to negotiate a multicast-only session over the bottom serial link. The router on the right is also instructed to inject network 192.192.25.0/24 into both its local U-RIB and M-RIB using the following command:
network 192.192.25.0 255.255.255.0 nlri unicast multicast
Once this network is injected into both RIBs, its network prefix will be advertised to the router on the right. However, the unicast nlri for this network will be advertised over the top BGP session and the multicast nlri over the bottom BGP session.
Module10.ppt
60
Incongruent Topologies
AS 123 AS 321 .1 .1 Unicast Traffic 192.168.100.0/24 .2
192.168.10.0/24 router bgp 123 . . . network 192.168.10.0 255.255.255.0 nlri unicast multicast neighbor 192.168.100.2 remote-as 321 nlri unicast neighbor 192.168.200.2 remote-as 321 nlri multicast
Sender
Module10. ppt
8/14/2001 3:35 PM
61 61
The first command instructs the router on the right to negotiate a unicastonly BGP session over the top serial link while the second command instructs it to negotiate a multicast-only session over the bottom serial link. The router on the right is also instructed to inject network 192.168.10.0/24 into both its local U-RIB and M-RIB using the following command:
network 192.168.10.0 255.255.255.0 nlri unicast multicast
Once this network is injected into both RIBs, its network prefix will be advertised to the router on the right. However, the unicast nlri for this network will be advertised over the top BGP session and the multicast nlri over the bottom BGP session.
Module10.ppt
61
Incongruent Topologies
AS 123 AS 321 .1 .1 Unicast Traffic 192.168.100.0/24 .2
192.168.10.0/24
Sender Unicast Information NLRI: NLRI: 192.192.25/24 192.192.25/24 AS_PATH: AS_PATH: 321 321 MED: MED: Next-Hop: 192.168.100.2 Next-Hop: 192.168.100.2 Routing Update
Module10. ppt
8/14/2001 3:35 PM
62 62
Module10.ppt
62
Incongruent Topologies
AS 123 AS 321 .1 .1 Unicast Traffic 192.168.100.0/24 .2
192.168.10.0/24
Multicast Information MP_REACH_NLRI: MP_REACH_NLRI: 192.192.25/24 192.192.25/24 AFI: AFI: 1, 1, Sub-AFI: Sub-AFI: 2 2 AS_PATH: AS_PATH: 321 321 MED: MED: Next-Hop: Next-Hop: 192.168.200.2 192.168.200.2 Routing Update
Sender
Module10. ppt
8/14/2001 3:35 PM
63 63
Module10.ppt
63
Incongruent Topologies
AS 123 AS 321 .1 .1 Unicast Traffic 192.168.100.0/24 .2
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
8/14/2001 3:35 PM
64 64
Module10.ppt
64
BGP stubs that dont have MBGP support need to get their prefixes into the Multicast backbone They get external routes via MBGP default or static default
Module10. ppt
8/14/2001 3:35 PM
65 65
Module10.ppt
65
Use command
neighbor <foo> translate-update [nlri multicast]
Module10. ppt
8/14/2001 3:35 PM
66 66
Module10.ppt
66
BGP IN Process
Arriving Unicast update intercepted by translate -update Front-end A translated Multicast update is created & passed to the IN Process Original Unicast update is passed on to the IN Process Both updates processed normally by the IN Process
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
67 67
Module10.ppt
67
AS 2
LO0 192.170.1.1
AS 4
192.192.25.0/24
AS 1
router bgp 1 . . . neighbor 192.168.1.1 neighbor 192.168.1.1 neighbor 192.170.1.1 neighbor 192.180.1.1 . . .
remote-as 4 translatetranslate -update nlri multicast remote-as 2 nlri unicast multicast remote-as 3 nlri unicast multicast
AS 3
LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
68 68
Module10.ppt
68
AS 2
LO0 192.170.1.1
AS 4
192.192.25.0/24
AS 1
AS 3
LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
69 69
Module10.ppt
69
AS 2
LO0 192.170.1.1
AS 4
192.192.25.0/24
AS 1
AS 3
Multicast Updates MP_REACH_NLRI: 192.192.25/24 AFI: 1, Sub-AFI: 2 (multicast) AS_PATH: 1, 4 MED: Next-Hop: ... LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
70 70
Module10.ppt
70
AS 2
LO0 192.170.1.1
AS 4
192.192.25.0/24
AS 1
AS 3
Unicast Updates NLRI: 192.192.25/24 AS_PATH: 1, 4 MED: Next-Hop: ... LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
71 71
Module10.ppt
71
Module10. ppt
8/14/2001 3:35 PM
72 72
Module10.ppt
72
You can do your typical set operations Used when connecting DVMRP access points into the MBGP backbone Used at strategic interconnect points with the old DVMRP MBONE
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
73 73
Module10.ppt
73
Multicast RIB
Network *>i192.1.1.0/24 *>i192.1.5.0/24 Next-Hop 192.20.2.2 192.20.2.2 Path ? ?
router bgp 100 redistribute dvmrp route -map dvmrp-to-bgp access-list 1 permit 192.1.0.0 0.0.255.255
Route 160.10.1.0/24 160.10.3.0/24 153.22.0.0/16 192.1.1.0/24 192.1.5.0/24 Hops 4 3 7 5 6
Module10. ppt
8/14/2001 3:35 PM
74 74
Module10.ppt
74
DVMRP Tunnel
AS 3
LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
75 75
Module10.ppt
75
DVMRP Tunnel
AS 3
LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
76 76
Module10.ppt
76
DVMRP Tunnel
AS 3
Multicast Updates MP_REACH_NLRI: 192.168/16 AFI: 1, Sub-AFI: 2 (multicast) AS_PATH: 1, 4 MED: Next-Hop: ... LO0 192.180.1.1
Module10. ppt
8/14/2001 3:35 PM
77 77
Module10.ppt
77
Can use typical match operations However, we recommend tail sites using DVMRP access to accept DVMRP default route
Module10. ppt
8/14/2001 3:35 PM
78 78
Module10.ppt
78
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
79
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.
Module10.ppt
80
Exception:
Unicast neighbors are automatically activated in the implied address-family ipv4 unicast block This default behavior can be overridden with:
no bgp default ipv4-unicast
Module10. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/14/2001 3:35 PM
81 81
Module10.ppt
81
Implied ipv4 unicast address family block with implied neighbor activate commands
Module10. ppt
8/14/2001 3:35 PM
82 82
Notice that the neighbor 172.16.1.2 remote-as 301 command also implies a neighbor 172.16.1.2 activate for ipv4 unicast NLRI exchange to neighbor 172.16.1.2. In addition, the no neighbor 172.16.11.2 activate overrides the implied neighbor 172.16.11.2 activate for ipv4 unicast NLRI exchange to neighbor 172.16.11.2. The bottom section of the example is the ipv4 multicast address family block. Notice that only neighbor 172.16.11.2 is activated for ipv4 multicast NLRI exchange. In this case, the no neighbor 172.16.1.2 activate is implied.
Module10.ppt
82
Module10. ppt
8/14/2001 3:35 PM
83 83
Module10.ppt
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 ! address-family ipv4 multicast neighbor 171.69.214.50 activate network 171.69.214.0 mask 255.255.255.0 exit-address-family
Overrides implied neighbor activate for the ipv4 unicast address family
Module10. ppt
8/14/2001 3:35 PM
84 84
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
Again, the neighbor 172.69.224.38 remote-as 2 command in this implied ipv4 unicast address family block has an implied neighbor 172.69.224.38 activate . This automatically activates ipv4 unicast NLRI exchange as was taking place in the original 12.0S configuration. In addition, the no neighbor 172.69.214.50 activate overrides the implied neighbor 172.69.214.50 activate that would normally occur in the implied ipv4 unicast block. This prevents ipv4 unicast NLRI exchange with this neighbor. The ipv4 multicast address family block also contains the neighbor 172.69.214.50 activate command which explicitly activates ipv4 multicast NLRI exchange with this neighbor Finally, the network 171.69.224.0 mask 255.255.255.0 command appears in both the implied ipv4 unicast address family block AND the explicit ipv4 multicast address family block. This causes this network to be injected into both the ipv4 Unicast and Multicast RIBs.
Copyright ? ?1998-2000, Cisco Systems, Inc.
Module10.ppt
84
Allows a clear separation of unicast and multicast configurations All ipv4 unicast commands are placed in a separate (explicit) address-family block
Module10. ppt
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
85
Module10. ppt
86 86
Module10.ppt
86
Debugging MBGP
show ip bgp neighbor
asimov# asimov# show show ip ip bgp bgp neighbor neighbor BGP BGP neighbor neighbor is is 10.0.10.3, 10.0.10.3, remote remote AS AS 1, 1, internal internal link link Index 2, Offset 0, Mask Index 2, Offset 0, Mask 0x4 0x4 BGP BGP version version 4, 4, remote remote router router ID ID 193.78.81.4 193.78.81.4 BGP BGP state state == Established, Established, table table version version == 4, 4, up up for for 22:32:50 22:32:50 Last Last read read 00:00:49, 00:00:49, hold hold time time is is 180, 180, keepalive keepalive interval interval is is 60 60 seconds seconds Neighbor NLRI negotiation: Neighbor NLRI negotiation: Configured Configured for for unicast unicast and and multicast multicast routes routes Peer Peer negotiated negotiated unicast unicast and and multicast multicast routes routes Exchanging Exchanging unicast unicast and and multicast multicast routes routes Minimum Minimum time time between between advertisement advertisement runs runs is is 5 5 seconds seconds Received Received 8916 8916 messages, messages, 00 notifications, notifications, 00 in in queue queue Sent Sent 8923 8923 messages, messages, 00 notifications, notifications, 00 in in queue queue Connections Connections established established 4; 4; dropped dropped 33 Last Last reset reset 22:32:59, 22:32:59, due due to to User User reset reset 00 accepted accepted unicast unicast prefix prefix consume consume 00 bytes bytes of of memory memory 00 history history unicast unicast paths paths consume consume 0 0 bytes bytes of of memory memory Connection Connection state state is is ESTAB, ESTAB, I/O I/O status: status: 1, 1, unread unread input input bytes: bytes: 0 0 Local Local host: host: 10.0.10.1, 10.0.10.1, Local Local port: port: 11004 11004 Foreign host: 10.0.10.3, Foreign port: 179 Foreign host: 10.0.10.3, Foreign port: 179
Module10. ppt
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.
Module10.ppt
87
Debugging MBGP
Old 12.0S Syntax
show ip bgp
asimov# asimov# show show ip ip bgp bgp BGP BGP table table version version is is 4, 4, 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, best, ii -- internal internal Origin Origin codes: codes: ii -- IGP, IGP, ee -- EGP, EGP, ?? -- incomplete incomplete Network Network *>10.0.100.0/24 *>10.0.100.0/24 Next Next Hop Hop 0.0.0.0 0.0.0.0 Metric Metric LocPrf LocPrf Weight Weight Path Path 00 32768 32768 ii
show ip mbgp
asimov# asimov# show show ip ip mbgp mbgp MBGP MBGP table table version version is is 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 *>10.0.70.0/24 *>10.0.70.0/24 *>10.0.80.0/24 *>10.0.80.0/24
Module10. ppt
Metric Metric LocPrf LocPrf Weight Weight Path Path 307200 32768 307200 32768 ii 10000 32768 10000 32768 ??
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 show ip mbgp Shows the contents of the U-RIB 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
88
Debugging MBGP
New 12.1 Syntax
show ip bgp ipv4 unicast
asimov# asimov# show show ip ip bgp bgp ipv4 ipv4 unicast unicast BGP BGP table table version version is is 4, 4, 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, best, ii -- internal internal Origin Origin codes: codes: ii -- IGP, IGP, ee -- EGP, EGP, ?? -- incomplete incomplete Network Network *>10.0.100.0/24 *>10.0.100.0/24 Next Next Hop Hop 0.0.0.0 0.0.0.0 Metric Metric LocPrf LocPrf Weight Weight Path Path 00 32768 32768 ii
Metric Metric LocPrf LocPrf Weight Weight Path Path 307200 32768 307200 32768 ii 10000 32768 ? 10000 32768 ?
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 show ip mbgp Shows the contents of the U-RIB 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
89
Debugging MBGP
Same for both Old and New Syntax
MBGP debug commands
debug ip mbgp updates
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
90
MBGPSummary
Module10. ppt
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.
Module10.ppt
91
Module10.ppt
92
Module10.ppt
92
ModuleN.ppt
8/21/2001 2:33 PM
Module11.ppt
Module Objectives
Understand the issues relating to Interdomain IP Multicast Explain fundamental concepts of MSDP Identify steps associated with configuring and debugging MSDP
Module11. ppt
8/21/2001 2:33 PM
2 2
Module11.ppt
Agenda
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
Module11.ppt
Past History
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
Past History
Problem
DVMRP cant scale to Internet sizes
Distance vector-based routing protocol Periodic updates
Full table refresh every 60 seconds
Table sizes
Internet > 40,000 prefixes
Stability
Hold-down, count-to-infinity, etc.
Module11. ppt
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
In the Future
BGMP (Border Gateway Multicast Protocol) Shared tree of domains
Bidirectional trees Explict join-model Joins sent toward root domain
8/21/2001 2:33 PM
6 6
Module11.ppt
In the Future
Domain A
BGMP Example
BR BR BR BR
Domain C
Domain B BR
Root 224.2.2.2
BR
Join Domain D
BR BR
Join
BR
BR
Join
BR
Join
BR
r
Domain G
r
Domain E
224.2.2.2
Module11. ppt
BR
BR
r
Domain F
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 lasthop 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.
Module11.ppt
In the Future
Domain A
BGMP Example
BR BR BR
Domain C
Domain B BR
Root 224.2.2.2
BR
s
BR
BR BR BR
r
BR BR BR BR
Domain G
r
Domain E
Module11. ppt
r
Domain F
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
In the Future
MASC (Multicast Address Set-Claim)
Multicast address space is hierarchical
Top of hierarchy is at an Internet exchange Children get address space from parent Results in aggregateable multicast address space
8/21/2001 2:33 PM
9 9
Module11.ppt
In the Future
Module11. ppt
8/21/2001 2:33 PM
10 10
Module11.ppt
10
8/21/2001 2:33 PM
11 11
Module11.ppt
11
Deployment
Each ISP puts their own administered RP attached to the interconnect That RP as well as all border routers run MBGP The interconnect runs dense-mode PIM
Module11. ppt
8/21/2001 2:33 PM
12 12
Module11.ppt
12
Public Interconnect
RP
PIM-SM iMBGP
ISP B
ISP C
PIM-SM
Module11. ppt
8/21/2001 2:33 PM
13 13
Module11.ppt
13
Module11. ppt
8/21/2001 2:33 PM
14 14
Module11.ppt
14
Solution: MSDP
Multicast Source Discovery Protocol
Module11. ppt
8/21/2001 2:33 PM
15 15
Module11.ppt
15
Agenda
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
16
MSDP Overview
Module11. ppt
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 SharedTree), it too can send a Join toward the source and join the source tree.
Module11.ppt
17
MSDP Overview
Module11. ppt
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 PIMSM. 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
18
MSDP Overview
MSDP peers talk via TCP connections
UDP encapsulation option
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.
Module11.ppt
19
MSDP Overview
MSDP Example
MSDP Peers
Domain E
RP Join (*, 224.2.2.2)
r
Domain C
RP
Domain B
RP RP
Domain D
RP
Domain A
Module11. ppt
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.
Module11.ppt
20
MSDP Overview
MSDP Example
MSDP Peers Source Active Messages SA SA
Domain E
RP
Domain C
RP SA
Domain B SA
RP SA
SA
RP
Domain D
s
Domain A
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.
Module11.ppt
21
MSDP Overview
MSDP Example
MSDP Peers
Domain E
RP
r
Domain C
RP
Join (S, 224 .2.2.2)
Domain B
RP
RP
Domain D
RP
s
Domain A
Module11. ppt
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.
Module11.ppt
22
MSDP Overview
MSDP Example
MSDP Peers Multicast Traffic
Domain E
RP
r
Domain C
RP
Domain B
RP RP
Domain D
RP
s
Domain A
Module11. ppt
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.
Module11.ppt
23
MSDP Overview
MSDP Example
MSDP Peers Multicast Traffic
Domain E
RP
Domain C
RP
Domain B
RP RP
Domain D
RP
s
Domain A
Module11. ppt
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 lasthop 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.
Module11.ppt
24
MSDP Overview
MSDP Example
MSDP Peers Multicast Traffic
Domain E
RP
r
Domain C
RP
Domain B
RP RP
Domain D
RP
s
Domain A
Module11. ppt
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
25
8/21/2001 2:33 PM
26 26
Module11.ppt
26
Agenda
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
27
MSDP Peers
MSDP establishes a neighbor relationship between MSDP peers
Peers connect using TCP port 639
Lower address peer initiates connection Higher address peer waits in LISTEN state
Peers send keepalives every 60 secs. (fixed) Peer connection reset after 75 seconds if no MSDP packets or keepalives are received
Module11. ppt
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
28
MSDP Peers
Exceptions:
When peering with only a single MSDP peer. When using an MSDP Mesh-Group.
Module11. ppt
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 URIB. 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.
Module11.ppt
29
MSDP Peers
LO0 220.220.8.1 RP LO0 220.220.16.1
RP
Interface Loopback 0 ip address 220.220.8.1 255.255.255.255 ip msdp peer 220.220.16.1 connectconnect-source Loopback0 ip msdp peer 220.220.32.1 connect connect-source Loopback0
B
LO0 220.220.32.1
MSDP peer connections are established using the MSDP peer configuration command
ip msdp peer <ip -address> [connect-source < intfc>]
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
30 30
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.
Module11.ppt
30
MSDP Peers
LO0 220.220.8.1 RP LO0 220.220.16.1
RP
Interface Loopback 0 ip address 220.220.26.1 255.255.255.255 ip msdp peer 220.220.8.1 connectconnect-source Loopback0 ip msdp peer 220.220.32.1 connectconnect-source Loopback0
B
LO0 220.220.32.1
MSDP peer connections are established using the MSDP peer configuration command
ip msdp peer <ip -address> [connect-source < intfc>]
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
31 31
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.
Module11.ppt
31
MSDP Peers
LO0 220.220.8.1 RP LO0 220.220.16.1
A
Interface Loopback 0 ip address 220.220.32.1 255.255.255.255 ip msdp peer 220.220.8.1 connectconnect-source Loopback0 ip msdp peer 220.220.16.1 connectconnect-source Loopback0
RP
B
LO0 220.220.32.1
MSDP peer connections are established using the MSDP peer configuration command
ip msdp peer <ip -address> [connect-source < intfc>]
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
32 32
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.
Module11.ppt
32
MSDP Peers
LO0 220.220.8.1 RP
ISP
RP
MSDP TCP/IP
Peer Connection
LO0 220.220.32.1
Stub-networks may use default peering without being an MBGP or BGP peer by using the MSDP default-peer configuration command.
ip msdp default-peer <ip-address>
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
33 33
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>
Module11.ppt
33
MSDP Peers
LO0 220.220.8.1 RP
ISP1
LO0 192.168.2.2 RP
ISP2
Interface Loopback 0 ip address 220.220.32.1 255.255.255.255 ip msdp defaultdefault-peer 220.220.8.1 ip msdp default default-peer 192.168.2.2
RP
MSDP TCP/IP
Peer Connection
LO0 220.220.32.1
Multiple default-peers may be configured in case connection to first default-peer goes down.
Module11. ppt
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.
Module11.ppt
34
MSDP Peers
LO0 220.220.8.1 RP
ISP1
LO0 192.168.2.2 RP
ISP2
X
Interface Loopback 0 ip address 220.220.32.1 255.255.255.255 ip msdp defaultdefault-peer 220.220.8.1 ip msdp default default-peer 192.168.2.2
RP
MSDP TCP/IP
Peer Connection
LO0 220.220.32.1
When connection to first default-peer is lost, the next one in the list is tried.
Module11. ppt
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.
Module11.ppt
35
MSDP Peers
LO0 220.220.8.1 RP
ISP
Interface Loopback 0 ip address 220.220.32.1 255.255.255.255 ip msdp peer 220.220.8.1 connectconnect-source Loopback0
RP
MSDP TCP/IP
Peer Connection
LO0 220.220.32.1
Stub-networks configured with only a single MSDP peer are treated in the same manner as when a single default-peer is configured. (i.e. BGP is not required.)
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.
Module11.ppt
36
MSDP Peers
LO0 220.220.8.1 RP
ISP1
LO0 192.168.2.2 RP
ISP2
Interface Loopback 0 ip address 220.220.32.1 255.255.255.255 ip msdp peer 220.220.8.1 connectconnect-source Loopback0 ip msdp peer 220.220.16.1 connectconnect-source Loopback0
RP
Peer Connection
LO0 220.220.32.1
Module11. ppt
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
37
MSDP Peers
Showing MSDP Peers
show ip msdp summary sj-mbone# show ip msdp summary MSDP Peer Status Summary Peer Address AS State 192.150.44.254 192.150.44.250 10888 Up 10876 Up
Module11. ppt
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
38
MSDP Peers
Showing MSDP Peer detail status
show ip msdp peer [<peer-address>]
sj-mbone# show ip msdp peer MSDP Peer 192.150.44.254 (pao5.pao4.verio.net), AS 10888 Description: PAIX Connection status: State: Up, Resets: 10, Connection source: none configured Uptime(Downtime): 1d19h, Messages sent/received: 148699/8689 Output messages discarded: 0 Connection and counters cleared 5d14h ago SA Filtering: Input filter: 111, route -map: none Output filter: 111, route-map: none SA-Requests: Input filter: none Sending SA -Requests to peer: disabled Peer ttl threshold: 32 Input queue size: 0, Output queue size: 0
Module11. ppt
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>]
Module11.ppt
39
Agenda
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
40
MSDP Messages
MSDP Message Contents
One or more messages (in TLV format)
Keepalives Source Active (SA) Messages Source Active Request (SA-Req) Messages Source Active Response (SA-Resp) Message
SA Message Contents:
Module11. ppt
IP Address of Originating RP Number of (S, G)s pairs being advertised List of active (S, G)s in the domain Encapsulated Multicast packet [optional]
8/21/2001 2:33 PM
41 41
Module11.ppt
41
MSDP Messages
MSDP Message Contents (cont.)
SA Request (SA-Req) Messages
Used to request a list of active sources for a group
Sent to an MSDP SA Cache Server Reduces Join Latency to active sources
Keepalive messages
Used to keep MSDP peer connection up
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
42 42
Module11.ppt
42
Receiving SA Messages
SA Message RPF Check
Accept SAs via a single deterministic path
Ignore all other arriving SAs Necessary to prevent SAs from looping endlessly
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
43
Receiving SA Messages
RPF Check Rules depend on peering
Rule 1: Sending MSDP peer = i(m)BGP peer Rule 2: Sending MSDP peer = e(m)BGP peer Rule 3: Sending MSDP peer != (m)BGP peer
Exceptions:
RPF check is skipped when:
Sending MSDP peer = Originating RP Sending MSDP peer = Mesh-Group peer Sending MSDP peer = only MSDP peer
(i.e. the default-peer or the only msdp-peer configured.)
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.
Module11.ppt
44
Receiving SA Messages
Determining Applicable RPF Rule
Using IP address of sending MSDP peer
Find (m)BGP neighbor w/matching IP address IF (no match found)
Use Rule 3
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
Module11.ppt
45
Warning:
This is not the same as the NextNext-hop of the path!!! i(m)BGP peers normally do not set NextNext-hop = Self. This is also not necessarily the same as the RouterRouter - ID!
8/21/2001 2:33 PM
46 46
Module11.ppt
46
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
Module11.ppt
47
AS5
172.16.6.1
AS7
RP F
172.16.5.1
i(m)BGP peer address = 172.16.3.1 (advertising best -path to RP) 172.16.4.1 D 172.16.3.1 E MSDP Peer address = 172.16.3.1
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
48 48
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.
Module11.ppt
48
AS5
172.16.6.1
AS7
RP F
172.16.5.1
i(m)BGP Peer address = 172.16.3.1 (advertising best -path to RP) 172.16.4.1 D 172.16.3.1 E MSDP Peer address = 172.16.4.1
X
RP A
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
49 49
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.
Module11.ppt
49
AS5
172.16.6.1
AS7
RP F
172.16.5.1
i(m)BGP Peer address = 172.16.3.1 (advertising best -path to RP) 172.16.4.1 D 172.16.20.1 172.16.3.1 E MSDP Peer address = 172.16.20.1
RP A
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
show show ip ip mbgp mbgp 172.16.6.1 172.16.6.1 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: (1 available, Paths: (1 available, best best #1) #1) 77 5, (received & used) 5, (received & used) 172.16.5.1 172.16.5.1 (metric (metric 68096) 68096) from from 172.16.3.1 172.16.3.1(172.16.3.1) (172.16.3.1)
8/21/2001 2:33 PM
50 50
Module11.ppt
50
AS5
172.16.6.1
AS7
RP F
172.16.5.1
i(m)BGP Peer address = 172.16.1.1 (advertising best -path to RP) 172.16.4.1 D RR 172.16.1.1 172.16.3.1 E MSDP Peer address = 172.16.3.1
X
A RP
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
51 51
Module11.ppt
51
Module11. ppt
8/21/2001 2:33 PM
52 52
Module11.ppt
52
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
8/21/2001 2:33 PM
53 53
Module11.ppt
53
AS5
172.16.6.1
AS7
F 172.16.5.1
RP
AS1
172.16.4.1 D RP
AS3
172.16.3.1 E RP First-AS in best-path to RP = AS of e(m)BGP Peer
A RP
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Path Path 33 ii 11 33 ii 11 ii 33 11 ii 33 77 ii 11 33 77 ii 33 77 55 ii 11 33 77 55 ii
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.
Module11.ppt
54
AS5
172.16.6.1
AS7
F 172.16.5.1
RP
AS1
172.16.4.1 D RP
AS3
172.16.3.1 E RP FirstFirst - AS in bestbest - path to RP != AS of e(m)BGP Peer
X
A RP
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
Router Router A's A's BGP BGP Table Table Network Next Network Next Hop Hop *> 172.16.3.1 *> 172.16.3.0/24 172.16.3.0/24 172.16.3.1 172.16.3.0/24 172.16.4.1 172.16.3.0/24 172.16.4.1 *> 172.16.4.1 *> 172.16.4.0/24 172.16.4.0/24 172.16.4.1 172.16.4.0/24 172.16.3.1 172.16.4.0/24 172.16.3.1 *> 172.16.3.1 *> 172.16.5.0/24 172.16.5.0/24 172.16.3.1 172.16.5.0/24 172.16.4.1 172.16.5.0/24 172.16.4.1 *> 172.16.3.1 *> 172.16.6.0/24 172.16.6.0/24 172.16.3.1 172.16.6.0/24 172.16.4.1 172.16.6.0/24 172.16.4.1
8/21/2001 2:33 PM
Path Path 33 ii 11 33 ii 11 ii 33 11 ii 33 77 ii 11 33 77 ii 33 77 55 ii 11 33 77 55 ii
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
55
8/21/2001 2:33 PM
56 56
Module11.ppt
56
AS5
172.16.6.1
AS7
F 172.16.5.1
RP
AS1
172.16.4.1 D RP
AS3
172.16.3.1 E RP First-AS in best-path to RP = AS of MSDP Peer
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
RP
Path Path 33 ii 11 33 ii 11 ii 33 11 ii 33 77 ii 11 33 77 ii 33 77 55 ii 11 33 77 55 ii
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.
Module11.ppt
57
AS5
172.16.6.1
AS7
F 172.16.5.1
RP
AS1
172.16.4.1 D RP
AS3
172.16.3.1 E RP First-AS in best-path to RP != AS of MSDP Peer
AS100
BGP Peer MSDP Peer SA Message
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
RP
Path Path 33 ii 11 33 ii 11 ii 33 11 ii 33 77 ii 11 33 77 ii 33 77 55 ii 11 33 77 55 ii
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
58
Module11. ppt
8/21/2001 2:33 PM
59 59
Module11.ppt
59
Debugging SA Origination
Module11. ppt
8/21/2001 2:33 PM
60 60
Module11.ppt
60
Processing SA Messages
Check mroute table for joined members.
i.e. (*,G) entry with an OIL that is != NULL
Send join toward source. Flood SA to all other MSDP peers except
The RPF peer. Any MSDP Peers that are in the same MSDP Mesh-Group. (More on that later.)
Note: SA messages are saved if SA-Caching has been enabled. (On by default after 12.1(?))
1998 2001, Cisco Systems, Inc. All rights reserved.
Module11. ppt
8/21/2001 2:33 PM
61 61
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.)
Module11.ppt
61
Filtering SA Messages
SA Filter Command:
ip msdp sa-filter {in|out} <peer-address> [list <acl>] [route-map <map>]
Filters (S,G) pairs to / from peer based on specified ACL. Can filter based on AS-Path by using optional route-map clause with a path-list acl. You can filter flooded and originated SAs based on a specific peer, incoming and outgoing.
Caution: Filtering SA messages can break the Flood and Join mechanism!
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
62 62
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 routemap <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.)
Module11.ppt
62
Originating SA Messages
Local Sources
A source is local if:
The router received a Register for (S, G), or The source is directly connected to RP
Other conditions may suppress SA messages from being originated for local sources.
More on that later.
Module11. ppt
8/21/2001 2:33 PM
63 63
Module11.ppt
63
Originating SA Messages
SA messages are triggered when any new source in the local domain goes active.
Initial multicast packet is encapsulated in an SA message.
This is an attempt at solving the bursty-source problem
Module11. ppt
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
64
Originating SA Messages
Encapsulating Initial Multicast Packets
Can bypass TTL-Thresholds
Original TTL is inside of data portion of SA message SA messages sent via Unicast with TTL = 255
Encapsulated multicast packets with a TTL lower than <ttl> for the specific MSDP peer are not forwarded or originated.
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
65
Originating SA Messages
Use msdp redistribute to control what SAs are originated.
Think of this as msdp sa-originate-filter function
ip msdp redistribute [list <acl>] [asn <aspath-acl>] [route-map <map>]
Filter by (S,G) pair using list <acl> Filter by AS-PATH using asn <aspath-acl> Filter based on route-map <map>
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-originatefilter because it is more descriptive of what the command actually does.
Module11.ppt
66
Originating SA Messages
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
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
67
MSDP SA Statistics
Showing MSDP SA counters
show ip msdp count sj-mbone# show ip msdp count SA State per ASN Counters, <asn>: <# sources>/<# groups> Total entries: 1359 24: 4/4, 25: 3/3, 52: 60/16, 70: 1/1 103: 2/2, 131: 8/6, 145: 130/61, 293: 15/13 668: 218/56, 683: 7/4, 704: 151/89, 1239: 10/10 1249: 25/10, 1275: 17/14, 1835: 41/28, 1879: 2/2 2513: 3/2, 2603: 4/4, 2914: 2/2, 3582: 24/20 3701: 6/5, 5640: 2/1, 5779: 242/169, 6194: 2/2 6461: 7/5, 7660: 91/29, 9270: 209/56, 10490: 16/12 10680: 3/3, 10888: 47/41, 11423: 7/1
Module11. ppt
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.
Module11.ppt
68
M flag indicates source was learned via MSDP A flag indicates source is a candidate for advertisement by MSDP
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
69 69
Module11.ppt
69
Agenda
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
Module11.ppt
70
MSDP Mesh-Groups
Optimises SA flooding
Useful when 2 or more peers are in a group
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.
Module11.ppt
71
MSDP Mesh-Groups
Configured with:
ip msdp mesh-group <name> <peer-address>
Peers in the mesh-group should be fully meshed. Multiple mesh-groups per router are supported.
Module11. ppt
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.
Module11.ppt
72
R1
SA
R4
SA
RP
RP
R2
SA
SA
R5
R3
ip ip ip ip ip msdp msdp msdp msdp msdp peer R1 peer R3 peer R4 mesh-group My-Group R1 mesh-group My-Group R3
ip ip ip ip ip
Module11. ppt
8/21/2001 2:33 PM
73 73
Module11.ppt
73
AS 2
Mesh-group as1-as2 Mesh-group as2-as3
RP
SA Loop!!!
RP
RP
RP
RP
AS1
Mesh-group as1 Mesh-group as1-as3
AS3
Mesh-group as3
DONT DO THIS!!!!
8/21/2001 2:33 PM
74 74
Module11.ppt
74
Agenda
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
Module11.ppt
75
MSDP SA Caching
With MSDP SA Caching
RPF check received SA If RPF OK
If RP for group, trigger any necessary (S,G) Joins Store in SA cache If new cache entry, immediately flood downstream If existing entry, reset entrys SA-expire-timer
Timer is reset to 6 minutes by receipt of another SA. When timer = zero, entry has expired and is deleted.
8/21/2001 2:33 PM
76 76
Module11.ppt
76
MSDP SA Caching
SA Caching Pros
Reduces join latency
RP maintains list of all active sources. Can immediately send (S,G) Joins as needed.
When a receiver joins the group. No need to wait for next (S,G) SA message to arrive
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
77
MSDP SA Caching
Without MSDP SA Caching
RPF check received SA If RPF OK
If RP for group, trigger any necessary (S,G) Joins Immediately flood SA downstream
Propagates the affect of any SA storms downstream Often results in TCP queue overflows and session resets
8/21/2001 2:33 PM
78 78
Module11.ppt
78
MSDP SA Caching
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
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
79
Module11. ppt
8/21/2001 2:33 PM
80 80
Module11.ppt
80
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.
Module11.ppt
81
MSDP SA Caching
SA-Request filtering
ip msdp filter-sa-request <ip-address> [list <acl>]
Module11. ppt
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
82
MSDP SA Caching
Listing the contents of the SA Cache
show ip msdp sa-cache [<group-or-source>] [<asn>]
sj-mbone# show ip msdp sa-cache MSDP Source-Active Cache - 1997 entries (193.92.8.77, 224.2.232.0), RP 194.177.210.41, MBGP/AS 5408, 00: 01:51/00:04:09 (128.119.167.221, 224.77.0.0), RP 128.119.3.241, MBGP/AS 1249, 0 6:40:59/00:05:12 (147.228.44.30, 233.0.0.1), RP 195.178.64.113, MBGP/AS 2852, 00: 04:48/00:01:11 (128.117.16.142, 233.0.0.1), RP 204.147.128.141, MBGP/AS 145, 00 :00:41/00:05:18 (132.250.95.60, 224.253.0.1), RP 138.18.100.1, MBGP/AS 668, 01:1 5:07/00:05:55 (128.119.40.229, 224.2.0.1), RP 128.119.3.241, MBGP/AS 1249, 06: 40:59/00:05:12 (130.225.245.71, 227.37.32.1), RP 130.225.245.71, MBGP/AS 1835, 1d00h/00:05:29 (194.177.210.41, 227.37.32.1), RP 194.177.210.41, MBGP/AS 5408, 00:02:53/00:03:07 (206.190.42.106, 236.195.60.2), RP 206.190.40.61, MBGP/AS 5779, 00:07:27/00:04:04 . . .
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) RP 194.177.210.41 MBGP/AS 5408 00:01:51/00:04:09 = Active source/group information = IP address of the originating RP. = The RP resides in AS 5408 = 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.
Module11.ppt
83
Other ISP
RR
RP RP
Customer
RP
Customer
Customer
8/21/2001 2:33 PM
84 84
Module11.ppt
84
The MSDP peers do not have to be an RP to forward SAs. Use i(m)BGP for the RPF check on the Pseudo (non-RP) peer. The Pseudo peer is often an i(m)BGP Route Reflector.
Module11. ppt
8/21/2001 2:33 PM
85 85
Module11.ppt
85
Agenda
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
Module11.ppt
86
Anycast RP
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.
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 loadbalancing. 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.
Module11.ppt
87
Anycast RP
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.
Module11.ppt
88
Anycast RP Overview
RP1 A A 10.1.1.1
MSDP
RP2 B B 10.1.1.1
Module11. ppt
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.)
Module11.ppt
89
Anycast RP Overview
Src
Src
RP1 A A 10.1.1.1
MSDP
SA SA
RP2 B B 10.1.1.1
Rec
Rec
Rec
Rec
Module11. ppt
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.
Module11.ppt
90
Anycast RP Overview
Src
Src
RP1
RP2 B B 10.1.1.1
Rec
X
Module11. ppt
A A 10.1.1.1
Rec
Rec
Rec
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.
Module11.ppt
91
Anycast RP Configuration
RP1
E0 S0
RP2
ip pim rp-address 10.0.0.1
10.1.1.1 via E0
Interface loopback 0 ip address 10.0.0.2 255.255.255.255 Interface loopback 1 ip address 10.0.0.1 255.255.255.255 ! ip msdp peer 10.0.0.3 connect-source loopback 0 ip msdp originator-id loopback 0
Interface loopback 0 ip address 10.0.0.3 255.255.255.255 Interface loopback 1 ip address 10.0,0.1 255.255.255.255 ! ip msdp peer 10.0.0.2 connect-source loopback 0 ip msdp originator-id loopback 0
Module11. ppt
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
92
Anycast RP Tips
Avoid Anycast RP/Router-ID conflicts
Insure Loopback address used for Anycast RP address is not accidentally used as a Router-ID.
This will mess up OSPF and BGP.
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.
Module11.ppt
93
Transit AS109
RP
int pos0/0 ip pim sparse-dense-mode 192.168.100.0/24 Receiver ip pim send-rp-announce Loopback0 scope 255 ip pim send-rp-discovery Loopback0 scope 255 int pos0/0 ip pim sparse-dense-mode
Module11. ppt
8/21/2001 2:33 PM
94 94
Module11.ppt
94
Transit AS109
RP
tail-gw#show ip pim rp mapping PIM Group-to-RP Mappings 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 Uptime: 21:57:41, expires: 00:02:08
Receiver
Module11. ppt
8/21/2001 2:33 PM
95 95
Module11.ppt
95
Transit AS109
RP
Receiver
Transit-tail#show ip pim rp mapping 192.168.100.0/24 PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent 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
8/21/2001 2:33 PM
96 96
Module11.ppt
96
Transit AS109
RP
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
8/21/2001 2:33 PM
97 97
Module11.ppt
97
Transit AS109
RP
- no RP / no MSDP
Module11. ppt
8/21/2001 2:33 PM
98 98
Module11.ppt
98
Transit AS109
RP
int pos0/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 192.168.100.0/24 Receiver ip msdp sa-filter out 1.1.1.2 111 ip msdp sa-filter in 1.1.1.2 111
8/21/2001 2:33 PM
99 99
Module11.ppt
99
Transit AS109
RP
192.168.100.0/24 Receiver
int ip ip ip
8/21/2001 2:33 PM
100 100
Module11.ppt
100
Transit AS109
RP
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
8/21/2001 2:33 PM
101 101
Module11.ppt
101
Transit AS109
RP
ip msdp peer 1.1.1.1 connect-source pos0/0 192.168.100.0/24 Receiver ip msdp peer 1.1.1.2 connect-source pos0/0
Module11. ppt
8/21/2001 2:33 PM
102 102
Module11.ppt
102
Transit AS109
RP
int pos0/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 192.168.100.0/24 Receiver ip msdp sa-filter out 1.1.1.2 111 ip msdp sa-filter in 1.1.1.2 111
8/21/2001 2:33 PM
103 103
Module11.ppt
103
Transit AS109
RP
192.168.100.0/24 Receiver
int ip ip ip
8/21/2001 2:33 PM
104 104
Module11.ppt
104
Transit AS109
RP
router bgp 100 network 192.168.100.0 nlri unicast multicast neighbor 1.1.1.2 remote-as 109 nlri unicast multicast neighbor 1.1.1.2 update-source pos0/0 192.168.100.0/24 Receiver router bgp 109 neighbor 1.1.1.1 remote-as 100 nlri unicast multicast neighbor 1.1.1.1 update-source pos 0/0
Module11. ppt
8/21/2001 2:33 PM
105 105
Module11.ppt
105
Transit AS109
RP
ip msdp peer 1.1.1.1 connect-source pos0/0 192.168.100.0/24 Receiver ip msdp peer 1.1.1.2 connect-source pos0/0
Module11. ppt
8/21/2001 2:33 PM
106 106
Module11.ppt
106
Transit AS109
Multicast Transit
Transit AS110
int pos0/0 ip pim sparse-mode 192.168.100.0/24 ip pim bsr-border ip multicast boundary 1 Receiver int pos1/0 ip msdp sa-filter out 1.1.1.2 111 ip msdp sa-filter in 1.1.1.2 111
pos0/0 1.1.2.2
Unicast Transit
Module11. ppt
8/21/2001 2:33 PM
107 107
Module11.ppt
107
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
int 192.168.100.0/24 ip ip ip pos0/0 pim sparse-mode pim bsr-border multicast boundary 1
Receiver
Unicast Transit
Module11. ppt
8/21/2001 2:33 PM
108 108
Module11.ppt
108
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver
Unicast Transit
Hey, this site knows no multicast so there is no PIM to constrain
Module11. ppt
8/21/2001 2:33 PM
109 109
Module11.ppt
109
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver router bgp 100 network 192.168.100.0 nlri unicast multicast neighbor 1.1.1.2 remote-as 109 nlri multicast neighbor 1.1.1.2 update-source pos 0/0 neighbor 1.1.2.2 remote-as 110 nrli unicast neighbor 1.1.2.2 update-source pos 1/0
1998 2001, Cisco Systems, Inc. All rights reserved.
Unicast Transit
Module11. ppt
8/21/2001 2:33 PM
110 110
Module11.ppt
110
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver router bgp 109 neighbor 1.1.1.1 remote-as 100 nlri multicast neighbor 1.1.1.1 update-source pos 0/0
Unicast Transit
Module11. ppt
8/21/2001 2:33 PM
111 111
Module11.ppt
111
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver 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.
Unicast Transit
8/21/2001 2:33 PM
112 112
Module11.ppt
112
Transit AS109
Multicast Transit
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver ip msdp peer 1.1.1.1 connect-source pos0/0
Unicast Transit
8/21/2001 2:33 PM
113 113
Module11.ppt
113
Transit AS109
Receiver
int pos0/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 192.168.100.0/24 int pos1/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 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
1998 2001, Cisco Systems, Inc. All rights reserved.
Transit AS110
pos0/0 1.1.2.2
Module11. ppt
8/21/2001 2:33 PM
114 114
Module11.ppt
114
Transit AS109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 int pos0/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 ip msdp sa-filter out 1.1.1.1 111 ip msdp sa-filter in 1.1.1.1 111
Receiver
Module11. ppt
8/21/2001 2:33 PM
115 115
Module11.ppt
115
Transit AS109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver int pos0/0 ip pim sparse-mode ip pim bsr-border ip multicast boundary 1 ip msdp sa-filter out 1.1.2.1 111 ip msdp sa-filter in 1.1.2.1 111
1998 2001, Cisco Systems, Inc. All rights reserved.
Module11. ppt
8/21/2001 2:33 PM
116 116
Module11.ppt
116
Transit AS109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiverrouter bgp 100 RP Unicast & Multicast network 192.168.100.0 nlri unicast multicast Transit neighbor 1.1.1.2 remote-as 109 nlri unicast multicast neighbor 1.1.1.2 update-source pos0/0 neighbor 1.1.2.2 remote-as 110 nlri unicast multicast neighbor 1.1.2.2 update-source pos1/0
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
117 117
Module11.ppt
117
Transit AS109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver
Transit
Module11. ppt
8/21/2001 2:33 PM
118 118
Module11.ppt
118
Transit AS109
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver
router bgp 110 neighbor 1.1.2.1 remote-as 100 nlri unicast multicast neighbor 1.1.2.1 update-source pos0/0
Module11. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 2:33 PM
119 119
Module11.ppt
119
Transit AS109
ip msdp peer 1.1.1.2 connect-source pos0/0 ip msdp peer 1.1.2.2 connect-source pos1/0
Transit AS110
pos0/0 1.1.2.2
192.168.100.0/24 Receiver ip msdp peer 1.1.1.1 connect-source pos0/0
8/21/2001 2:33 PM
120 120
Module11.ppt
120
Module11.ppt
121
Module11.ppt
121
Module12. ppt
8/21/2001 3:39 PM
Module7.ppt
Objectives
Upon completion of this module, you will be able to perform the following tasks:
Describe the principles of Source-Specific Multicast and configure it. Describe the principles of Bidir-PIM and configure it.
Module12. ppt
8/21/2001 3:39 PM
2 2
Module7.ppt
Agenda
Module12. ppt
8/21/2001 3:39 PM
3 3
Module7.ppt
Module12. ppt
8/21/2001 3:39 PM
4 4
Module7.ppt
Module12. ppt
8/21/2001 3:39 PM
5 5
Module7.ppt
SSM Overview
Hosts initiate join requests for a specific source(s) within a group. Last-hop router sends (S,G) join toward source without joining/creating shared tree. Content identified by both source and group address instead of group address alone. Eliminates shared tree, simplifying address allocation.
Dissimilar content sources can use same group without fear of interfering with each other.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
6 6
Module7.ppt
Host learns of source, group/port First-hop learns of source, group/port First-hop send PIM (S,G) Join
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 lasthop 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.
Module7.ppt
Result: Shortest path tree rooted at the source, with no shared tree.
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
Module7.ppt
Module12. ppt
8/21/2001 3:39 PM
9 9
Module7.ppt
Filtering SA Messages
Use ip msdp sa-redistribute at RP.
Stops SA message origination in the 232/8 range.
Module12. ppt
8/21/2001 3:39 PM
Module7.ppt
10
IGMPv3 will only be active ... IF supported in last-hop routers AND IF supported in host operating systems AND IF supported in receiver applications
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
11 11
Module7.ppt
11
8/21/2001 3:39 PM
12 12
Module7.ppt
12
8/21/2001 3:39 PM
13 13
Module7.ppt
13
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
Module7.ppt
14
IGMP v3lite:
Provide for a partial IGMPv3 API on IGMPv1/v2 hosts. Enables us to write and run IP SSM applications NOW
8/21/2001 3:39 PM
15 15
Module7.ppt
15
8/21/2001 3:39 PM
16 16
Module7.ppt
16
Module12. ppt
8/21/2001 3:39 PM
17 17
Module7.ppt
17
URD Overview
The user (receiver) clicks on one of the links A cgi script runs that provides the host an HTTP redirect to TCP port 659 When the host sends the redirect, it is intercepted by the last-hop router (directly connected to the host)
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.
Module7.ppt
18
Http:/www.broadcast.com/sports.htm
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
19 19
Module7.ppt
19
Module12. ppt
8/21/2001 3:39 PM
20 20
Module7.ppt
20
8/21/2001 3:39 PM
21 21
Module7.ppt
21
8/21/2001 3:39 PM
22 22
Module7.ppt
22
8/21/2001 3:39 PM
23 23
Module7.ppt
23
8/21/2001 3:39 PM
24 24
Module7.ppt
24
Module12. ppt
8/21/2001 3:39 PM
25 25
Module7.ppt
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
Module7.ppt
26
Module12. ppt
8/21/2001 3:39 PM
27 27
Module7.ppt
27
...
...
Module12. ppt
8/21/2001 3:39 PM
28 28
Module7.ppt
28
8/21/2001 3:39 PM
29 29
Module7.ppt
29
4. The browser will look into his application mappings for this content-type x-sdp, and start the appropriate application - our old player.
Transferring from sessions.broadcast.com
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
30 30
Module7.ppt
30
4 While doing so, the browser will also hand over the Actual URL content to that application (typically in a file as a command line argument for the application).
Transferring from sessions.broadcast.com
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
31 31
Module7.ppt
31
5. From this URL, the application knows the multicast group IGMPv1/v2 to use, and it will Join Group join to that group. 232.3.4.5
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
32 32
Module7.ppt
32
6. But the application will not yet receive traffic, because it is an IP SSM group, and this old applications group membership report is not good enough alone !
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
33 33
Module7.ppt
33
7. Back to the browser who continues to interpret and display his original HTML page...
Transferring from sessions.broadcast.com
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
34 34
Module7.ppt
34
...
<FRAME Currently showing SRC="http://www.broadcast.com:659/urd-helper? Euro 2000 Soccer group=232.3.4.5&source=192.44.81.5 live from " Brussels NAME=URD command URL" > England : Germany
...
8/21/2001 3:39 PM
35 35
Module7.ppt
35
The Internet
The Host
The last hop router running 12.1(3)T or later and enabled for
ip urd
on the interface to the host
Module12. ppt
8/21/2001 3:39 PM
36 36
Module7.ppt
36
The Internet
The Host
The last hop router running 12.1(3)T or later and enabled for
ip urd
on the interface to the host
Module12. ppt
8/21/2001 3:39 PM
37 37
Module7.ppt
37
The Internet
The Host
The last hop router running 12.1(3)T or later and enabled for
ip urd
on the interface to the host
If the browser tries to retrieve the URL http://www.broadcast.com:659/urdhelper?group=232.3.4.5&source=192.44.81.5 Then it wants to open a TCP connection to www.broadercast.com, port 659
Module12. ppt
8/21/2001 3:39 PM
38 38
Module7.ppt
38
The Internet
The Host
The last hop router running 12.1(3)T or later and enabled for
ip urd
on the interface to the host
If the browser tries to retrieve the URL http://www.broadcast.com:659/urdhelper?group=232.3.4.5&source=192.44.81.5 Then it wants to open a TCP connection to www.broadercast.com, port 659 But it only gets up to the first-hop router, who intercepts all TCP connections to port 659, whatever destination address they are for !
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
39 39
Module7.ppt
39
GET /urd-helper?
www.broadcast.com
The Host
ip urd
on the interface to the host
The router disguises itself as a web server and listens to what the host want to have.
Module12. ppt
8/21/2001 3:39 PM
40 40
Module7.ppt
40
GET /urd-helper?
www.broadcast.com
The Host
I understand this URL request, ip urd I understand this URL request, lets join letsremember rememberto toPIM-SS PIM-SS join on the remember interfaceto toto the host lets PIM-SSM join to 232.3.4.5 for source to group group 232.3.4.5 for source group 232.3.4.5 for source 192.44.81.5, 192.44.81.5, 192.44.81.5, if, or as soon as I Ialso have an if, or as soon as also have an if, or as soon as I also have an IGMPv1/v2 IGMPv1/v2group groupmembership membership report for 232.3.4.5 from this IGMPv1/v2 group membership report for 232.3.4.5 from this report interface for interface 232.3.4.5 from this interface
Module12. ppt
8/21/2001 3:39 PM
41 41
Module7.ppt
41
GET /urd-helper?
The Host
HTTP/1.1 200 OK The last hop router running 12.1(3)T or later and Server: cisco IOS enabled for Content-Type: text/html <html> ip urd on the interface to the host <body> Retrieved URL string successfully </body> </html>
Module12. ppt
8/21/2001 3:39 PM
42 42
Module7.ppt
42
The Internet
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
Module7.ppt
43
The Internet
And finally the picture arrives and is being forwarded as long as the application runs and sends the IGMPv1/v2 membership reports
Module12. ppt
8/21/2001 3:39 PM
44 44
Module7.ppt
44
And all the user could notice, is the string returned by the router (may be hidden)!
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
45 45
Module7.ppt
45
URD Configuration
No plugins required
Complete host platform independence
Nothing to configure on the host URL easily added to WWW server HTML pages
No additional CGI scripts required.
Module12. ppt
8/21/2001 3:39 PM
46 46
Module7.ppt
46
Port 659 assigned by IANA for Cisco URD. URD - URL Rendezvous Directory
Name still carries the idea that it is also quite simple to write a CGI-Script to completely emulate an RP, i.e.: add web pages, where you would click onto if you are a source, and the script would then create the URD command URLs for the receivers.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
47 47
Module7.ppt
47
8/21/2001 3:39 PM
48 48
Module7.ppt
48
Module12. ppt
8/21/2001 3:39 PM
49 49
Module7.ppt
49
HSIL HSIL
Module12. ppt
8/21/2001 3:39 PM
50 50
Module7.ppt
50
HSIL HSIL
Module12. ppt
8/21/2001 3:39 PM
51 51
Module7.ppt
51
HSIL HSIL
Join (G)
Module12. ppt
8/21/2001 3:39 PM
52 52
Module7.ppt
52
HSIL HSIL
Cisco IOS 12.1(3)T or later router with ip igmp v3lite enabled UDP Port:659
Membership report INCLUDE (S,G)
Join (G)
8/21/2001 3:39 PM
53 53
Module7.ppt
53
8/21/2001 3:39 PM
54 54
Module7.ppt
54
SSM Summary
Module12. ppt
8/21/2001 3:39 PM
55 55
Module7.ppt
55
Agenda
Module12. ppt
8/21/2001 3:39 PM
56 56
Module7.ppt
56
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
Module7.ppt
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
Module7.ppt
58
8/21/2001 3:39 PM
59 59
Module7.ppt
59
8/21/2001 3:39 PM
60 60
Module7.ppt
60
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
8/21/2001 3:39 PM
61 61
Module7.ppt
61
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
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.
Module7.ppt
62
RP Receiver
Sender/ Receiver
8/21/2001 3:39 PM
63 63
Module7.ppt
63
RP Receiver
Sender/ Receiver
Source Traffic forwarded bidirectionally using (*,G) state. Shared Tree Source Traffic Receiver
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
64 64
Module7.ppt
64
RP Receiver
Sender/ Receiver
( * , G) State created only along the Shared Tree. Shared Tree Source Traffic Receiver
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
65 65
Module7.ppt
65
The DF is responsible for forwarding traffic upstream towards the RP. No special treatment is required for local sources.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
66 66
Module7.ppt
66
RP
N2
DF Join to DF
N3
Join to DF
N4
R1
Shared Tree
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
R2
8/21/2001 3:39 PM
67 67
Module7.ppt
67
Join
N1
RP
N2
DF
N3
N4
R1
Shared Tree
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
R2
8/21/2001 3:39 PM
68 68
Module7.ppt
68
RP
N2
DF
N3
N4
R1
Shared Tree
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
R2
8/21/2001 3:39 PM
69 69
Module7.ppt
69
RP
N2
DF
S1
N3 N4
R1
R2
Module12. ppt
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).
Module7.ppt
70
S2
RP
N1
N2
DF
S1
N3 N4
R1
R2
8/21/2001 3:39 PM
71 71
Module7.ppt
71
8/21/2001 3:39 PM
72 72
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
Module7.ppt
72
DF Election Messages
Offer: Used to advertise local metrics to reach the RP. Winner: Used by a DF announcing or re-asserting its status. Backoff Backoff: : Used by a DF to acknowledge receipt of a better Offer. Pass: Used by an acting DF to pass the DF responsibility to a better candidate.
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.
Module7.ppt
73
Initial Election
On RP discovery send Offer with metric to RP.
N1
RP
N2
Offer 10
N3
N4
Module12. ppt
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.
Module7.ppt
74
Initial Election
On RP discovery send Offer with metric to RP. We are better Neighbors compare with own metric and N1 send Offer only if Offer 8 better.
N3
RP
N2
Offer 10
N4
Module12. ppt
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.
Module7.ppt
75
Initial Election
On RP discovery send Offer with metric to RP. We are better Neighbors compare with own metric and N1 send Offer only if Offer 8 better.
N3
RP
We lose
N2
Offer 10
N4
Module12. ppt
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.
Module7.ppt
76
Initial Election
On RP discovery send Offer with metric to RP. Neighbors compare with own metric and send Offer only if better. After repeating 3 uncontested Offers, send a Winner and assume DF role.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
RP
We Win!
N1 N2
Winner 8
N3
N4
8/21/2001 3:39 PM
77 77
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.
Module7.ppt
77
Initial Election
Winner message informs the other routers who is DF.
We Win!
N1
RP
DF is N1
N2
Winner 8 DF is N1
N3 N4
DF is N1
Module12. ppt
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.
Module7.ppt
78
DF Preemption
New candidate sends improved Offer.
RP
Candidate
N1 N2
DF
Offer 6
N3
N4
Module12. ppt
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.
Module7.ppt
79
DF Preemption
New candidate sends improved Offer. DF responds with Backoff instructing candidate to wait.
N1 RP
Candidate
N2
DF
Backoff 6
N3
N4
Module12. ppt
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.
Module7.ppt
80
DF Preemption
New candidate sends improved Offer. DF responds with Backoff instructing candidate to wait. Before backoff period expires, old DF stops forwarding and sends Pass.
N1 RP
Candidate
N2
Pass N2
N3
N4
Module12. ppt
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.
Module7.ppt
81
DF Preemption
New candidate sends improved Offer. DF responds with Backoff instructing candidate to wait. Before backoff period expires, old DF stops forwarding and sends Pass. On receipt candidate becomes DF.
N1 RP
Candidate
N2
Pass N2
DF
N3
N4
Module12. ppt
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.
Module7.ppt
82
DF Preemption
New candidate sends improved Offer. DF responds with Backoff instructing candidate to wait. Before backoff period expires, old DF stops forwarding and sends Pass. On receipt candidate becomes DF. Other routers hear Pass, learn N2 is now DF.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
RP
N1
N2
Pass N2
DF
N3
N4
DF is N2
DF is N2
83 83
8/21/2001 3:39 PM
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.
Module7.ppt
83
Restarted
N1 N2
Offer 8
DF
N3
N4
Module12. ppt
8/21/2001 3:39 PM
84 84
Module7.ppt
84
Winner 6
DF
N4
Module12. ppt
8/21/2001 3:39 PM
85 85
Module7.ppt
85
N1
Offer ?
N2
DF
N3
N4
Module12. ppt
8/21/2001 3:39 PM
86 86
Module7.ppt
86
N1
N2
DF
Winner 8
N3
N4
Module12. ppt
8/21/2001 3:39 PM
87 87
Module7.ppt
87
DF Failures
Detecting DF Failures
Downstream Routers
RP RPF info no longer points to DF.
Non-Downstream Routers
PIM Neighbor timeout of DF.
Module12. ppt
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.
Module7.ppt
88
Worse metric:
Sends 3 Winner messages with new metric. Other routers can respond with a better Offer.
8/21/2001 3:39 PM
89 89
Module7.ppt
89
Additional Robustness
DF re-announces sending Winner message when new PIM neighbors are discovered. Periodic Winner messages can be sent for RPs with active groups.
Module12. ppt
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.
Module7.ppt
90
DF Advantages
DF election enforces a single forwarder for traffic in both directions between a link and the RP. DF is responsible for originating Joins for local receivers thus eliminating loops that were previously possible due to DR placement. Customized unicast routes in downstream routers do not affect the choice of the forwarding router. This eliminates loops due to misconfiguration.
Module12. ppt
1998 2001, Cisco Systems, Inc. All rights reserved.
8/21/2001 3:39 PM
91 91
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.
Module7.ppt
91
Module12. ppt
8/21/2001 3:39 PM
92 92
Module7.ppt
92
Module12. ppt
8/21/2001 3:39 PM
93 93
Module7.ppt
93
Module12.ppt
94
Module7.ppt
94