Outline

11: ❒ IP ❒ Multicast IP Multicast ❍ Design choices ❍ Distance Vector Multicast Routing Protocol (DVMRP) Last Modified: ❍ Core Based Trees (CBT) ❍ Protocol Independent Multicast (PIM) 4/9/2003 1:15:00 PM ❍ Border Gateway Multicast Protocol (BGMP) ❒ Issues in IP Multicast Deplyment Based on slides by Gordon Chaffee Berkeley Multimedia Research Center URL: http://bmrc.berkeley.edu/people/chaffee

4: 4a-1 4: Network Layer 4a-2

What is multicast?

❒ ❒ 1 to N communication Problem Sender ❍ ❒ Nandwidth-conserving technology that Sending same data to reduces traffic by simultaneously many receivers via unicast is inefficient delivering a single stream of information to R multiple recipients ❒ Example ❒ Examples of Multicast ❍ Popular WWW sites ❍ Network hardware efficiently supports become serious multicast transport bottlenecks • Example: Ethernet allows one packet to be received by many hosts ❍ Many different protocols and service models • Examples: IETF IP Multicast, ATM Multipoint

4: Network Layer 4a-3 4: Network Layer 4a-4

Multicast IP Multicast Introduction

❒ Efficient one to many Sender ❒ Efficient one to many data distribution data distribution ❍ Tree style data distribution ❍ Packets traverse network links only once R ❒ Location independent addressing ❍ IP address per multicast group ❒ Receiver oriented service model ❍ Applications can join and leave multicast groups ❍ Senders do not know who is listening ❍ Similar to television model ❍ Contrasts with telephone network, ATM

4: Network Layer 4a-5 4: Network Layer 4a-6

1 IP Multicast Group Management Protocol (IGMP)

❒ Service ❒ Protocol for managing group membership ❍ All senders send at the same time to the same ❍ IP hosts report multicast group memberships to group neighboring routers ❍ Receivers subscribe to any group ❍ Messages in IGMPv2 (RFC 2236) ❍ Routers find receivers • Membership Query (from routers) ❒ • Membership Report (from hosts) Unreliable delivery • Leave Group (from hosts) ❒ Reserved IP addresses ❒ Announce-Listen protocol with Suppression ❍ 224.0.0.0 to 239.255.255.255 reserved for ❍ Hosts respond only if no other hosts has multicast responded ❍ Static addresses for popular services (e.g. ❒ Session Announcement Protocol) Soft State protocol

4: Network Layer 4a-7 4: Network Layer 4a-8

IGMP Example (1) IGMP Example (2) MembershipLeave ReportGroup 1 3 1 3

Network 1 Network 2 Network 1 Network 2 Router Router 2 4 2 4 ❒ Host 3 joins conference ❍ Sends IGMP Membership Report message ❒ Host 1 begins sending packets ❒ Router begins forwarding packets onto Network 2 ❍ No IGMP messages sent ❒ Host 3 leaves conference ❍ Packets remain on Network 1 ❍ Sends IGMP Leave Group message ❒ Router periodically sends IGMP Membership Query ❍ Only sent if it was the last host to send an IGMP Membership Report message

4: Network Layer 4a-9 4: Network Layer 4a-10

Source Specific Filtering: IGMPv3 Multicast Routing Discussion

❒ Adds Source Filtering to group selection ❒ What is the problem? ❍ Receive packets only from specific source ❍ Need to find all receivers in a multicast group addresses ❍ Need to create spanning tree of receivers ❍ Receive packets from all but specific source ❒ Design goals addresses ❍ Minimize unwanted traffic ❒ Benefits ❍ Minimize router state ❍ Helps prevent denial of service attacks ❍ Scalability ❍ Better use of bandwidth ❍ Reliability ❒ Status: Internet Draft?

4: Network Layer 4a-11 4: Network Layer 4a-12

2 Data Flooding Reverse Path Forwarding (RPF)

❒ Send data to all nodes in network ❒ Simple technique for building trees ❒ Problem ❒ Send out all interfaces except the one with ❍ Need to prevent cycles the shortest path to the sender ❍ Need to send only once to all nodes in network ❍ Could keep track of every packet and check if it had ❒ In unicast routing, routers send to the previously visited node, but means too much state destination via the shortest path ❒ In multicast routing, routers send away R2 from the shortest path to the sender

R1 R3

Sender 4: Network Layer 4a-13 4: Network Layer 4a-14

Reverse Path Forwarding Example Data Distribution Choices

1. Router R1 checks: Did the data Sender packet arrive on the interface ❒ with the shortest path to the Source rooted trees 2. Router R2 accepts packets Sender? Yes, so it accepts the ❍ sent from Router R1 because packet, duplicates it, and State in routers for each sender forwards the packet out all other that is the shortest path to the ❍ Sender. The packet gets sent interfaces except the interface Forms shortest path tree from each sender to out all interfaces. that is the shortest path to the R1 sender (i.e the interface the receivers packet arrived on). ❍ Minimal delays from sources to destinations Drop ❒ Shared trees 3. Router R2 drops R2 R3 packets that arrive from Drop ❍ All senders use the same distribution tree Router R3 because that is not the shortest path to ❍ State in routers only for wanted groups the sender. Avoids cycles. ❍ No per sender state (until IGMPv3) R4 R5 R6 R7 ❍ Greater latency for data distribution

4: Network Layer 4a-15 4: Network Layer 4a-16

Source Rooted vs Shared Trees Distance Vector Multicast Routing (DVMRP)

Often does not use optimal path from ❒ Steve Deering, 1988 A A source to destination. ❒ Source rooted spanning trees ❍ Shortest path tree ❍ Minimal hops (latency) from source to receivers B C B C ❒ Extends basic distance vector routing ❒ Flood and prune algorithm ❍ Initial data sent to all nodes in network(!) using Reverse D D Path Forwarding Source Shared Tree Routers maintain ❍ Rooted Trees state for each sender Prunes remove unwanted branches in a group. Traffic is heavily ❍ concentrated on State in routers for all unwanted groups some links while ❍ Periodic flooding since prune state times out (soft state) others get little utilization.

4: Network Layer 4a-17 4: Network Layer 4a-18

3 DVMRP Algorithm Truncated Reverse Path Multicast Example

Sender ❒ Truncated Reverse Path Multicast Router R2 accepts packets sent from ❍ Router R1 because that is the Optimized version of Reverse Path Forwarding shortest path to the Sender. ❍ Truncating Unlike Reverse Path Forwarding, • No packets sent onto leaf networks with no receivers which simply forwards out all but R1 the incoming interface, DVMRP’s ❍ Still how “truncated” is this? Reverse Path Multicast maintains a list of child links for each sender. It ❒ sends packets only out child links, Pruning not parent or sibling links. This Siblings ❍ means Router R2 will not forward R2 R3 Prune messages sent if no downstream receivers data from the Sender to Router R3. ❍ State maintained for each unwanted group ❒ Grafting ❍ On join or graft, remove prune state and propagate graft R4 R5 R6 R7 message Receiver Truncation: no packets forwarded onto leaf networks with no receivers 4: Network Layer 4a-19 4: Network Layer 4a-20

DVMRP Pruning Example DVMRP Grafting Example

Sender Sender

R1 R1

Prune Graft Join from Receiver 2 causes router to remove R2 R3 R2 R3 its prune state and send a Join message up Prune State toward the Sender.

Prune Prune Prune Graft

R4 R5 R6 R7 R4 R5 R6 R7 Receiver 2 joins Receiver Receiver 1 multicast Membership group Report

4: Network Layer 4a-21 Receiver4: Network 2 Layer 4a-22

DVMRP Problems Core Based Trees (CBT)

❒ State maintained for unwanted groups ❒ Attributes ❒ Bandwidth intensive ❍ Single shared tree per group => sparse trees ❍ Periodic data flooding per group ❍ Large number of senders • No explicit joins, and prune state times out ❍ Routing tables scale well, size = O(Groups) ❍ Not suitable for heterogeneous networks ❍ Bi-directional tree ❒ Poorly handles large number of senders ❍ Scaling = O(Senders, Groups) ❒ Problems of distance vector routing ❍ slow convergence ❍ cycles due to lack of global knowledge

4: Network Layer 4a-23 4: Network Layer 4a-24

4 Group Management in CBT Sending Data in CBT (1)

Core Case 1: Sender is a member Core

Join Ack of the multicast group, and the first hop router is on the Ack R R shared tree. R R

Join

R R R4 R R R4

Ack Ack

Join Join Sender R1 R R2 R3 R R1 R R2 R3 R5

2. Receiver 2 also joins the multicast Packets from the Sender are 1. Receiver 1 joins the multicast group, causing Router R3 to join the propagated by routers on the group, causing Router R2 to join the shared tree by sending a Join shared tree by sending out all shared tree by sending a Join message toward the Core. Router interfaces that are branches of message toward the Core. The Core R4 is already part of the shared the tree except the interface the sends an explicit ACK back to to Receiver 1 Receiver 2 tree, so it adds R3 to the shared tree Receiver 1 Receiver 2 packet arrived on. Router R2. and sends back an ACK. 4: Network Layer 4a-25 4: Network Layer 4a-26

Sending Data in CBT (2) Protocol Independent Multicast (PIM) 2. The Core decapsulates the encapsulated packets, and it Case 2: Sender is not a Core distributes them out the shared ❒ member of the multicast tree. Uses unicast routing table for topology group, and the first hop ❒ router is not on the shared R R Dense mode (PIM-DM) tree. ❍ For groups with many receivers in local/global region R R R4 ❍ Encapsulated Like DVMRP, a flood and prune algorithm Data Packet ❒ Sparse mode (PIM-SM) Receiver ❍ R1 R R2 R3 R5 For groups with few widely distributed receivers Sender 1. Router R1 is not on the shared ❍ tree, so it does an IP-in-IP Builds shared tree per group, but may construct encapsulation of packets from the source rooted tree for efficiency Sender, and it the encapsulated packets to the Core. ❍ Explicit join Receiver Receiver

4: Network Layer 4a-27 4: Network Layer 4a-28

PIM Sparse Mode Group Management in PIM-SM

Rendezvous Point ❒ Hybrid protocol that combines features of RP DVMRP and CBT Join R R ❒ Suited to widely distributed, heterogeneous networks Join R R R ❒ Shared tree centered at Rendezvous Point

(RP) Join ❒ Shared tree introduces sources to receivers DR1 R DR2 R R ❒ Source specific trees for heavy traffic flows 1. Receiver 1 joins the multicast 2. Routers along the path to RP ❒ group. Designated Router DR2 create router state for the group, Unidirectional distribution tree sends a Join message toward the adding themselves to the shared tree. RP. Periodically, DR2 resends the Receiver 1 Join message in case it was lost.

4: Network Layer 4a-29 4: Network Layer 4a-30

5 PIM-SM Source Specific Sending Data in PIM-SM Bypass Rendezvous Rendezvous RP Point (RP) RP Point (RP) 2. The join request reaches DR1, and DR1 adds DR2 R to the source specific tree R R for Sender 1. Data from R Sender 1 begins flowing on the source specific tree to DR2. R R R R R R Encapsulated Encapsulated Data Packet Data Packet Source Source Source Specific Join Specific Join Specific Prune

DR1 R DR2 R DR DR1 R3 DR2 R DR

Sender 1 Sender 1 3. The RP decapsulates the packet 1. Sender 1 begins sending to a multicast group. 1. Designated Router DR2 sees traffic from 3. When DR2 sees traffic from Sender 1 and sends it out the shared tree. Sender 1 at a rate > threshold. It sends a source coming from R3, it sends a Source Specific 2. Designated Router DR1 encapsulates the specific join request toward Sender 1. Prune message toward RP. This removes DR2 packets from Sender 1 in Register messages and from the shared tree. unicasts them to RP. Receiver 1 Receiver 1

4: Network Layer 4a-31 4: Network Layer 4a-32

RP Joins Source Specific Tree Problems with PIM

1. RP sees traffic from Sender 1 at a 3. When RP sees unencapsulated rate > threshold. It sends source RP traffic from Sender 1, it sends a specific join request toward Sender 1. Register Stop message to DR1. ❒ Global broadcasts of all Rendezvous Points Source DR1 then stops sending Specific Join R R encapsulated traffic to RP. ❒ Sensitive to location of RP Source Specific Join ❒ No administrative control over multicast R R R traffic; policy controls lacking Encapsulated Data Packet Source ❒ Specific Join Conceived as inter-domain, but now considered intra-domain DR1 R DR2 R DR

Sender 1

2. The join request reaches DR1, and DR1 adds RP to the source specific tree for Sender 1. Data from Sender 1 begins flowing on the source specific tree to RP. Receiver 1

4: Network Layer 4a-33 4: Network Layer 4a-34

Classification of Tree Building Border Gateway Multicast Protocol Choices (BGMP) ❒ Flood network topology to all routers ❒ Administrative control of multicast traffic ❍ Link state protocol ❒ ❍ Multicast Extensions to OSPF (MOSPF) Hierarchical allocation ❒ Flood and prune ❒ Uses BGP for routing tables ❍ Distance Vector Multicast Routing Protocol ❒ No global broadcasts of anything (DVMRP) ❒ Bi-directional shared multicast routing ❍ Protocol Independent Multicast Dense Mode (PIM-DM) tree ❒ Explicit join ❍ Core Based Trees (CBT) ❍ Protocol Independent Multicast Sparse Mode (PIM-SM)

4: Network Layer 4a-35 4: Network Layer 4a-36

6 IP Multicast in the Real World Commercial Motivation

❒ Problem ❍ Traffic on Internet is growing about 100% per year ❍ Router technology is getting better at 70% per year ❍ Routers that are fast enough are very expensive ❒ ISPs need to find ways to reduce traffic ❒ Multicast could be used to… ❍ WWW: Distribute data from popular sites to caches throughout Internet ❍ Send video/audio streams multicast ❍ Software distribution

4: Network Layer 4a-37 4: Network Layer 4a-38

ISP Concerns Economics of Multicast

❒ Multicast causes high network utilization ❒ One packet sent to multiple receivers ❍ One source can produce high total network load ❒ Sender ❍ Experimental multicast applications are relatively high + Benefits by reducing network load compared to bandwidth: audio and video unicast ❍ Flow control non-existent in many multicast apps + Lower cost of network connectivity ❒ Multicast breaks telco/ISP pricing model ❒ ❍ Currently, both sender and receiver pay for bandwidth Network service provider ❍ Multicast allows sender to buy less bandwidth while - One packet sent can cause load greater than reaching same number of receivers unicast packet load ❍ Load on ISP network not proportional to source data rate + Reduces overall traffic that flows over network ❒ Receiver = Same number of packets received as unicast

4: Network Layer 4a-39 4: Network Layer 4a-40

Multicast Problems Current ISP Multicast Solution

❒ Multicast is immature ❒ Restrict senders of multicast data ❍ Immature protocols and applications ❒ ❍ Tools are poor, difficult to use, debugging is difficult Charge senders to distribute multicast ❍ Routing protocols leave many issues unresolved traffic • Interoperability of flood and prune/explicit join ❍ Static agreements • Routing instability ❒ Multicast development has focused on academic ❒ Do not forward multicast traffic problems, not business concerns ❍ Some ISP’s offer multicast service to ❍ Multicast breaks telco/ISP traffic charging and customers (e.g. UUNET UUCast) management models ❍ ❍ Routing did not address policy ISP beginning to discuss peer agreements • PIM, DVMRP, CBT do not address ISP policy concerns • BGMP addresses some ISP concerns, but it is still under development

4: Network Layer 4a-41 4: Network Layer 4a-42

7 Multicast Tunneling Multicast Tunneling Example (1)

Multicast Router 2 ❒ decapsulates IP-in-IP Problem packets. It then forwards them using ❍ Multicast Router 1 Encapsulated Not all routers are multicast capable Reverse Path encapsulates multicast Data Packet Multicast Multicast. ❍ packets for groups Router 2 Want to connect domains with non-multicast that have receivers outside of network 1. routers between them It encapsulates them UR1 UR2 as unicast IP-in-IP packets. ❒ Solution Multicast Router 1 ❍ Encapsulate multicast packets in unicast packet Unicast Routers ❍ Tunnel multicast traffic across non-multicast

routers Sender 1 Receiver ❍ We will see more examples of tunneling later Network 2

Network 1

4: Network Layer 4a-43 4: Network Layer 4a-44

Multicast Tunneling Example (2) MBone

❒ MBONE ❍ Virtual Network Topology Multicast capable virtual network, subset of Internet ❍ Native multicast regions connection with tunnels ❒ In 1992, the MBone was created to further the

MR1 MR2 development of IP multicast ❍ Experimental, global multicast network Virtual ❍ Interfaces Served as a testbed for multicast applications development • vat -- audio tool •vic --video tool • wb -- shared whiteboard

4: Network Layer 4a-45 4: Network Layer 4a-46

MBone Usage Future?

❒ Dramatic increase in use... ❍ Research: telecollaboration, protocol development ❍ Learning: conferences, seminars, and classes ❍ Entertainment: Rolling Stones concert ❒ Leads to much higher bandwidth demand ❍ Groups range from < 10 to 1000’s, will grow to millions ❍ Number of programs/groups -- thousands of channels

4: Network Layer 4a-47 4: Network Layer 4a-48

8 Outtakes Multicast

❒ History ❍ Long history of usage on shared medium networks ❍ Data distribution ❍ Resource discovery: DHCP , Bootp, ARP ❒ Ethernet ❍ Broadcast (software filtered) ❍ Multicast (hardware filtered) ❒ Multiple LAN multicast protocols ❍ DECnet, AppleTalk, IP

4: Network Layer 4a-49 4: Network Layer 4a-50

Source Specific Filtering: IGMPv3 IGMPv3 Source Filtering (1) Sender 2 ❒ Adds Source Filtering to group selection ❍ Receive packets only from specific source addresses R2 ❍ Receive packets from all but specific source R1 R3 addresses Sender 1 Sender 3 ❒ Benefits Senders 1, 2, and 3 are sending to the R4 ❍ Helps prevent denial of service attacks same multicast group. If using an IGMPv2 join, router R1 would forward traffic from all ❍ Better use of bandwidth The receiver sent an IGMPv3 Group- senders to router R4. However, in this case with IGMPv3, no traffic from ❒ and-Source-Specific message to join Status: Internet Draft? the multicast group but to exclude all Sender 1 is forwarded to router R4. traffic from Sender 1. Receiver

4: Network Layer 4a-51 4: Network Layer 4a-52

IGMPv3 Source Filtering (2) Scoping Multicast Traffic Sender 2

❒ TTL based ❍ Based on Time to Live (TTL) field in IP header R2 R1 R3 ❍ Only packets with a TTL > threshold cross Sender 1 Sender 3 boundary ❒ Administrative scoping Senders 1, 2, and 3 are sending to R4 In an IGMPv2 join, routers R1, R2, ❍ Set of addresses is not forwarded past domain the same multicast group. and R3 would forward traffic. In the case of IGMPv3, only router R3 ❍ More flexible than TTL based. The Receiver sent an IGMPv3 forwards traffic to router R4. Group-and-Source Specific ❒ Scoped addresses message to join the multicast group and receive traffic from ❍ Receiver 224.0.0.* never leaves subnet only Sender 3.

4: Network Layer 4a-53 4: Network Layer 4a-54

9 Administrative Scoping TTL Scoping Example Example

CAIRN High Speed Network Receiver 1 Receiver 2 UC Berkeley Network To Rest To Rest of World of World R1 R2 R3 R4

Network 2 Host Network 1 TTL=2 TTL=3 TTL=4 TTL=33

R1 R2 R3 R4 TTL=4 ❒ Administrative scoping allows traffic to be limited to a region based on its multicast TTL=1 Network 3 Network 4 R4 blocks traffic with TTL < 32 group address, resulting in more flexible network configurations.

❒ The Host can send traffic that is limited to only the CAIRN High Speed Network, to only the UC Berkeley Network, to both, or to the rest of the world. Sender Receiver 3 ❒ 239.2.0.0 - 239.2.255.255: Traffic scoped to only the CAIRN High Speed Network ❒ 239.3.0.0 - 239.3.255.255: Traffic scoped to only the UC Berkeley Network ❒ 239.4.0.0 - 239.4.255.255: Traffic scoped to both the CAIRN and UC Berkeley Networks ❒ 224.0.1.0 - 238.255.255.255: Traffic scoped to the rest of the world

4: Network Layer 4a-55 4: Network Layer 4a-56

Reliable Multicast PIM Rendezvous Point (RP)

❒ Some applications need the same data to be ❒ Requirement delivered reliably to many receivers ❍ Different groups map to different RPs ❍ Distributed collaboration tools (e.g. shared whiteboard) ❒ ❍ Stock history Bootstrap Router (BSR) ❍ Software distribution ❍ Dynamically elected ❒ Status ❍ Constructs a set of RP IP addresses based on ❍ Many different proposals received Candidate-RP messages ❍ Proposals solve some problems but have not considered ❒ How do routers know RP for a group? commercial limitations of multicast ❍ ❍ Still exploring applications for reliable multicast Bootstrap Router broadcasts Bootstrap message with RP set to PIM ❍ Hash function on group address maps to an RP

4: Network Layer 4a-57 4: Network Layer 4a-58

Border Gateway Multicast Protocol (BGMP)

❒ Motivation ❍ Hierarchy for multicast routing ❍ Combine design of multicast address allocation and multicast routing ❍ Inter-domain routing protocols need administrative control of multicast traffic ❒ Scalability issues ❍ Need to minimize router state ❍ Need to minimize control messages ❍ Only send data where it is needed

4: Network Layer 4a-59 4: Network Layer 4a-60

10 Administrative Control of Choosing a Shared Tree Root Traffic NTT BBN 1. Using PIM, the Rendezvous 2. Therefore, the Rendezvous Point for the multicast group is Point for a session started by chosen by a hash function on the Host Z at the Stanford multicast group. University might be in BBN at Router A. The PIM shared A tree would cross ISP 2 even 1. The shortest path from ISP 1 ISP 2 though there are no receivers ISP 1 Intel to the Stanford ISP 2 in that direction. University goes through IBM. However, IBM does 2. IBM installs an not want to act as a transit administrative policy that network for multicast does not propagate any data sent by Intel over its multicast routes of Intel 3. If Host Z at the Stanford networks. senders in outside of University initiates a IBM’s internal network. conference, the root of the shared tree should be in the B Stanford University domain Z (e.g. Router B). The shared Y tree only develops in places Intel IBM Stanford with interested receivers University Intel IBM Stanford University downstream.

4: Network Layer 4a-61 4: Network Layer 4a-62

Multicast Address Allocation Multicast Address Allocation Architecture ❒ Problem ❒ Multicast Address Set Claim (MASC) ❍ ❍ Multicast addresses are a limited resource Protocol to allocate multicast address sets to domains ❍ Algorithm: Listen and claim with collision detection ❍ Current multicast address allocation scheme ❍ does not scale and makes multicast routing Makes hierarchy available to routing infrastructure more difficult ❒ Address Allocation Protocol (AAP) ❒ Solution ❍ Protocol for allocating multicast addresses within domains ❍ ❍ Use dynamically allocated addresses Used by Multicast Address Allocation Servers (MAAS) ❒ ❍ Address allocation location determines root of MDCHP (Multicast DHCP) shared tree ❍ Protocol for end hosts to request multicast address ❍ ❍ Hierarchical address allocation scales better Extension to DHCP (Dynamic Host Configuration Protocol) and helps multicast routing

4: Network Layer 4a-63 4: Network Layer 4a-64

Multicast Address Allocation Example Address Allocation Message Exchange Local Remote MASC MAAS MAAS Router for Client MASC Server Server Domain

AAP Address Set Advertisement MDHCP address request AAP address claim TCP MASC Exchanges AAP address collide MASC MASC Allocation Domain AAP address claim

AAP timeout Multicast AAP period (eg 2 seconds)

MASC address claim MDHCP address allocation AAP address set near exhaustion warning MAAS MAAS MAAS MAAS after MASC claim interval (eg 1 day) MDHCP MDHCP MDHCP Periodic AAP address claim

AAP Address Set Advertisement

4: Network Layer 4a-65 4: Network Layer 4a-66

11 Operational Problems Backchannel Tunneling

BBN ❒ Debugging is difficult Virtual Network ❒ Misconfigured routers inject unicast routing Physical Network tables into multicast routing tables ISP 2 ISP 1 A Cornell UC Berk ❒ Univ Black holes ISP 1 ISP 2 Univ of ❍ Cisco to Cisco tunneling using DVMRP doesn’t work Illinois B XZ • Routes exchanged, but no data flows Backchannel tunnel causes Backchannel B to send multicast traffic ❍ Tunnel from RPF checks on different routers think multicast traffic X to Z to X through Z. This is bad should be coming from the other router for the network. ❒ Backchannel tunnels B ❍ Improper tunnels cause non-optimal routing behavior X Y Z UC Berkeley University of Illinois Cornell University

4: Network Layer 4a-67 4: Network Layer 4a-68

Debugging Multicast Problems

❒ Local LAN debugging ❍ tcpdump • tcpdump • tcpdump igmp ❒ Routing debugging ❍ mrinfo ❍ mstat ❍ mtrace

4: Network Layer 4a-69

12