1. Debugging Multicast John Barlow

2. 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 ?)

3. Overview Terminology Intro. to multicast & protocols Good design Caveats The document you should read/use –Brief walkthrough

4. Terminology SA RP RPF mroute MSDP MBGP IGMP PIM-sparse PIM-sparse-dense PIM-dense

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

6. 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 …

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

8. 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#

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

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

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

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

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

14. MSDP edge1.act#sh ip msdp summary MSDP Peer Status Summary Peer Address AS State Uptime/ Reset SA Peer Name Downtime Count Count 202.0.98.1 18062 Up 3d01h 2 15 loopback0.edge1.qld.grangenet.net 202.0.98.68 18062 Up 1w0d 4 0 loopback0.edge1.vic.grangenet.net 202.0.98.102 64607 Up 2w6d 5846 0 g102.anu.edu.au 202.0.98.118 65522 Down 4w6d 0 0 port2.extreme.apac.edu.au

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

16. MBGP edge1.act#sh ip mbgp summary BGP … Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 202.0.98.1 4 18062 50194 49994 465329 0 0 3d01h 21 202.0.98.12 4 18062 50110 50213 465329 0 0 3w2d 11 202.0.98.13 4 18062 336849 50255 465329 0 0 3w2d 4348

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

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

19. Intro. to Multicast Protocol Independent Multicast (PIM) Peering between PIM clouds –MBGP –MSDP

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

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

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

23. 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 …

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

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

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

27. Good Design Monitor packets blocked by firewalls and access lists PIM-sparse mode unless you need dense (ie: Novell), then PIM-sparse- dense

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

29. Caveats Reverse path forwarding (reverse path verification) – and a lack of error messages Wireless 10Mbps half duplex … hubs

30. The Doco. you should use The following is an Internet2 debugging guide: http://www.aarnet.edu.au/engineering/tr ouble/multicast/troubleshoot- multicast.pdfhttp://www.aarnet.edu.au/engineering/tr ouble/multicast/troubleshoot- multicast.pdf

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

32. References General multicast notes: http://www.aarnet.edu.au/network/design/multicast/ http://www.aarnet.edu.au/network/design/multicast/ IPTV software download: http://videolab.uoregon.edu/download.html 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://www.aarnet.edu.au/engineering/trouble/multicast/ http://beaconserver.accessgrid.org:9999/