Debugging Multicast

John Barlow

Status

• Multicast enabled on all GrangeNet routers.

• Multicast enabled in all AARNet RNOs except for NT RNO.

• Multicast running natively across SCCN and throughout GrangeNet and AARNet

• Curtin, VU, JCU, UoW, CSIRO, UQ, CQU connected (whole-of-campus ?)

Overview

• Terminology

• Intro. to multicast & protocols

• Good design

• Caveats

• The document you should read/use– Brief walkthrough

Terminology

• SA• RP• RPF• mroute• MSDP• MBGP• IGMP

• PIM-sparse• PIM-sparse-dense• PIM-dense

SA (Source Active)

• Information about a singular source of multicast packets– Source address (eg: 192.94.63.41)– Multicast group (eg: 233.2.178.9)– Rendezvous Point (remote or local …)– AS#, age, peer address

• Your router should have a cache of all sources for all multicast groups

SA

• edge1.act#sh ip msdp sa-cache • MSDP Source-Active Cache - 2867 entries• (62.40.99.241, 224.0.1.32), RP 62.40.102.39,

MBGP/AS 20965, 06:13:11/00:05:23, Peer 202.0.98.13

• (62.40.103.30, 224.0.1.32), RP 62.40.102.9, MBGP/AS 20965, 06:12:47/00:05:23, Peer 202.0.98.13

• …

RP (Rendezvous Point)

• A repository for multicast source information.– Local source information– Remote source information

• Acts as central “bootstrap” point for subscribing to a multicast source.

RP

edge1.act#sh ip pim rp mapping

PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static

RP: 202.0.98.49 (loopback0.edge1.act.grangenet.net)

edge1.act#

Reverse Path Forwarding (RPF)

• Used to discard/ignore multicast packets that might be looping (ie: multicast packet claiming to come from a source must flow in the interface that the unicast routing table says you should take to get _to_ the source).

• Also used to discard MSDP SA packets

RPF

edge1.act#sh ip rpf 192.94.63.10 RPF information for clix.aarnet.edu.au (192.94.63.10) RPF interface: Vlan23 RPF neighbor: vlan23.gig0-

0.aarnet1.yarralumla.aarnet.edu.au (202.0.98.82) RPF route/mask: 192.94.63.0/24 RPF type: mbgp RPF recursion count: 0 Doing longest-match lookups across tables Multicast Multipath enabled

Multicast ROUTE (mroute)

• When some multicast is flowing, there will be an “mroute” entry that tells the router which interface the SA is coming in on, and which interface(s) it is going out of.

mroute

edge1.act#sh ip mroute active Active IP Multicast Sources - sending >= 4 kbps

Group: 233.29.147.222, (?) Source: 192.94.63.35 (arrowroot.aarnet.edu.au) Rate: 9 pps/7 kbps(1sec), 6 kbps(last 30 secs), 1

kbps(life avg) Source: 192.231.212.2

(lattice.broadway.aarnet.net.au) Rate: 9 pps/6 kbps(1sec), 6 kbps(last 30 secs), 1

kbps(life avg)

Multicast Source Discovery Protocol (MSDP)

• Is a unicast (TCP) protocol to pass SA information from one RP to another RP

• You should configure “MSDP sa-cache” to save SA entries (saves time compared to the alternative of querying peers)

MSDP

edge1.act#sh ip msdp summary MSDP Peer Status SummaryPeer Address AS State Uptime/ Reset SA Peer Name Downtime Count Count202.0.98.1 18062 Up 3d01h 2 15

loopback0.edge1.qld.grangenet.net202.0.98.68 18062 Up 1w0d 4 0

loopback0.edge1.vic.grangenet.net202.0.98.102 64607 Up 2w6d 5846 0

g102.anu.edu.au202.0.98.118 65522 Down 4w6d 0 0

port2.extreme.apac.edu.au

Multiprotocol Border Gateway Protocol (MBGP)

• Used to feed reverse path routing information (can be used to enforce policy to route multicast separately from unicast routes)

• Also used for IPv6 unicast, IPv6 multicast (MBGP is an expansion on standard BGP to handle lots of things)

MBGP

edge1.act#sh ip mbgp summary BGP …Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd202.0.98.1 4 18062 50194 49994 465329 0 0 3d01h 21202.0.98.12 4 18062 50110 50213 465329 0 0 3w2d 11202.0.98.13 4 18062 336849 50255 465329 0 0 3w2d 4348

Internet Group Membership Protocol (IGMP)

• Protocol that a host uses to chat with a router to subscribe (and possibly unsubscribe) from a multicast source

• Several versions exist (usually want the latest, version 3, if you have any option)

• Switches can “snoop” IGMP so they can olptimise which ports do _not_ get some multicast source

PIM sparse / dense

• PIM-sparse, PIM-dense, PIM-sparse-dense

• Sparse mode uses the RP and is network efficient

• Dense mode does not use the RP, flood-and-prune mechanism to inform every router, required for some protocols (eg: Novell).

Intro. to Multicast

• Protocol Independent Multicast (PIM)

• Peering between PIM clouds– MBGP– MSDP

Protocol Independent Multicast

• Operates with some arbitrary administrative domain (eg: your campus).

• Provides RPF (Reverse Path Forwarding) verification by using the unicast routing table (which can be populated by any protocol: OSPF, ISIS, static, etc) – hence the name.

Intro. to PIM

• Sources tell the nearest router about themselves, and the nearest router passes that information to the RP.

• Consumers ask the nearest router to “join” them to multicast source(s), and the router passes this request to the RP.

Intro. to PIM

• Need to specify an RP (Rendezvous Point) which doesn’t have to be inside your PIM cloud, but it is nice to have it inside (self-contained, more robust).

• Client subscribes to multicast via RP, but this quickly changes to a “native” subscription.

Intro. to PIM

• After the RP has set up the multicast join, the router nearest the consumer has enough information to “join” independently of the RP, so it does this, and the RP stops forwarding the multicast.

• The RP passes the multicast stream in an encapsulated unicast packet …

Intro. to PIM Peering

• Became politically impractical to run one PIM cloud for the entire Internet

• MSDP– My RP and your RP swap SA information

• MBGP– I can enforce policy on multicast routing– Remote site might need your MBGP info.

Good Design

• No tunnels – native multicast everywhere (easier debugging)

• Advertise your prefix(es) via MBGP(or have the RNO do so on your behalf)

• Keep unicast and multicast on the same link (debugging and problems are simpler) – avoid special policy for multicast where possible

Good Design

• Single RP to start with (easier debugging)– Use a dedicated loopback interface with

a /32 address– Later upgrade to “anycast RP” for

robustness

Good Design

• Monitor packets blocked by firewalls and access lists

• PIM-sparse mode unless you need dense (ie: Novell), then PIM-sparse-dense

Caveats

• IGMP snooping– If you have enough switch CPU, use it

• Ghost– Uses multicast … block it at your border …– You may not have multicast officially

enabled, but might need IGMP snooping to help when running ghost

• Access lists & firewalls

Caveats

• Reverse path forwarding (reverse path verification) – and a lack of error messages

• Wireless

• 10Mbps half duplex …

• hubs

The Doco. you should use

The following is an Internet2 debugging guide:

• http://www.aarnet.edu.au/engineering/trouble/multicast/troubleshoot-multicast.pdf

Brief Walkthrough

• Router-by-router process between source and destination.

• Need to have a source trying to transmit and a consumer trying to receive (even if this isn’t working !)– A good way to achieve this is with the multicast

beacon service• If you are an access-grid site, subscribe to the access-

grid beacon• Otherwise (maybe as well) subscribe to the AARNet

beacon server

References

• General multicast notes:http://www.aarnet.edu.au/network/design/multicast/

• IPTV software download:http://videolab.uoregon.edu/download.html

• Troubleshooting guides:http://www.aarnet.edu.au/engineering/trouble/multicast/in particular, check the NANOG 2003 tutorial link !

• http://beaconserver.accessgrid.org:9999/