• Like
Debugging Multicast John Barlow Status
Upcoming SlideShare
Loading in...5
×
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
456
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
28
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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/trouble/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/
    • 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/