1. Engineering Workshops Internet2 IPv6 Multicast Workshop Albuquerque, New Mexico February 2006

2. Engineering Workshops 2 TODO Anyone want to provide some Juniper info? –Some config examples for enabling embedded-RP, multicast BGP peerings and scope boundaries would be good Interdomain lab details –dbeacon details, beacon client and web access at NYSERNet? –vlc details, hopefully vlc stream from NYSERNet Suggestions for other things to add? I think we got spare time, but I’m out of ideas Anything that needs to be expanded or explained better? Feel free to contribute slides or change mine –Or tell me what you think I should change

3. Engineering Workshops 3 Acknowledgements Stig Venaas Bill Owens UNINETT NYSERNet

4. Engineering Workshops 4 Preliminaries Introductions –Instructors –Students Who has Juniper experience? Workshop schedule

5. Engineering Workshops 5 Contents Overview and Addressing Multicast on the LAN –Lab 1 Intradomain Multicast –Lab 2 Interdomain Multicast –Lab 3

6. Engineering Workshops 6 Overview and Addressing

7. Engineering Workshops 7 Current IPv6 multicast deployment A tunneled multicast network called M6Bone was established in France in 2001 Today more than 50 sites from four continents are connected Networks like Abilene, GEANT and NORDUnet have native IPv6 multicast in their production networks and native peerings E.g. NYSERNet in NY and UNINETT (the Norwegian academic network) have also native connectivity to Abilene and NORDUnet resp. So there is native IPv6 multicast all the way from NY to Norway The M6Bone has both a web site and a mailing list for information and discussion on IPv6 multicast –Web site at http://www.m6bone.net/ –Mailing list m6bone@ml.renater.fr The largest router vendors have IPv6 multicast support on most of their routers. Many other vendors have some support, or plan to offer support soon

8. Engineering Workshops 8 IPv6 multicast addresses 11111111FlagsScopeGroup ID 8 bits4 bits 112 bits Flag bits: 0 R P T T = 0 – permanent IANA assigned address T = 1 – transient address (not IANA) P = 1 – derived from unicast prefix (RFC 3306) R = 1 – embedded-RP address (RFC 3956) Scopes: 0 Reserved 1 Interface local 2 Link local 3 Reserved 4 Admin local 5 Site local 6-7 Unassigned (admin) 8 Organization local 9-D Unassigned (admin) E Global F Reserved IPv6 multicast addresses are in the range FF00::/8

9. Engineering Workshops 9 Unicast prefix based addresses 11111111FlagsScopeResrvdPlenPrefixGroup ID 8 bits4 bits 8 bits 64 bits32 bits Unicast prefix based addresses are defined in RFC 3306 Flags are set to 3 (P=T=1) Reserved must be 0 Plen is the length of the prefix used Prefix is a unicast prefix The group ID consists of any 32 bits In this way every site will have many multicast addresses unique to them One can also use /64 prefixes to get addresses unique to a link Example: –Site with unicast prefix 2001:db8:1::/48 –Example multicast address ff3e:30:2001:db8:1:0:dead:beef

10. Engineering Workshops 10 Embedded-RP addresses 11111111FlgsScpResRIIDPlenPrefixGroup ID 8 bits4444864 bits32 bits Embedded-RP addresses are defined in RFC 3956 Variation of the unicast prefix based addresses Flags are set to 7 (R=P=T=1). R is a new flag for embedded-RP Reserved must be 0 RIID contains the last 4 bits of the RP address Plen is the length of the prefix used Prefix is a unicast prefix The group ID consists of any 32 bits One may use /64 prefixes as well to have an RP per link Example: –Site with unicast prefix 2001:db8:1::/48 can pick RP address 2001:db8:1::a –Example multicast address ff3e:0a30:2001:db8:1:0:dead:beef

11. Engineering Workshops 11 SSM addresses 11111111FlagsScopeResrvdPlenPrefixGroup ID 8 bits4 bits 8 bits 64 bits32 bits SSM addresses are special subset of unicast prefix based addresses Flags are set to 3 (P=T=1) Reserved must be 0 Plen is set to 0 Prefix is set to all zeroes The group ID consists of any 32 bits This results in ff3x::/96 for SSM (where x is any scope) 111111113Scope000Group ID 8 bits4 bits 8 bits 64 bits32 bits

12. Engineering Workshops 12 Group IDs Should generally be 32 bits, although it is possible to use 112 bits when not using any of the specific addressing schemes When mapping IPv6 multicast groups to link-layer destination addresses, the last 32 bits are used. So one should try to always have different group IDs for different groups. RFC 3307 specifies a scheme with 32-bit IDs as follows –0x00000001 - 0x3fffffff Groups assigned by IANA –0x40000000 - 0x7fffffff Group IDs assigned by IANA –0x80000000 - 0xffffffff Server/host allocation Note that IANA may assign group IDs, not just groups. This is something like scope relative addresses for IPv4. Whenever using unicast prefix based addresses, embedded-RP addresses or SSM, you should pick group IDs according to this scheme

13. Engineering Workshops 13 Multicast on the LAN

14. Engineering Workshops 14 Multicast on the LAN IPv6 (also unicast) relies on multicast on links –Neighbor discovery uses a number of groups ff02::1, all-nodes link-local multicast ff02::1:ffxx:xxxx, solicited node multicast address –xx:xxxx are the last 24 bits of the unicast address The mapping from IPv6 addresses to ethernet multicast mac addresses is done by setting the first two octets to 0x33 and the last four to the last four octets of the IPv6 address –Hence as we said on the previous slide, unique group IDs result in unique mac addresses

15. Engineering Workshops 15 MLD – Multicast Listener Discovery MLD is used between hosts and routers to signal which groups (and sources) a host is interested in Similar to IGMP for IPv4, but uses ICMP MLDv1 – RFC 2710 supports only ASM, similar to IGMPv2 MLDv2 – RFC 3810 also supports SSM, similar to IGMPv3 Router with lowest address on link elected as querier Querier periodically (125s default) sends queries to ff02::1 to see whether there still is interest for current groups MLD is used for all groups of scope 2 or larger –Except for ff02::1 For robustness messages are retransmitted Both the robustness and the timers can be tuned by querier

16. Engineering Workshops 16 MLDv1 When hosts receive a general query they set a timer for each group they are interested in to a random value (0-10s default), and sends a report per group when the group’s timer expires –No report is sent if the host receives another host’s report before timer expires –The report is sent to the group itself (the one being reported) Host sends unsolicited report when it starts listening to a group If host stops listening to a group, it sends done message to ff02::2 When querier receives done message, it sends a multicast- address specific query to check if there still are listeners –Sent to the group itself –Hosts that are interested respond after random delay (with suppression)

17. Engineering Workshops 17 MLDv2 1/2 When hosts receive a general query they wait for a random period of time (0-10s default), and then reports all state –There may be multiple groups in one packet –Reports are sent to ff02::16 and no suppression –This makes life easier for snooping switches Host sends unsolicited report when listening state changes –No done message, reports are used When querier sees that a host leaves a source/group, it sends a multicast-address specific query to check if there still are listeners –Sent to the group itself –All hosts that are interested respond after random delay

18. Engineering Workshops 18 MLDv2 2/2 MLDv2 has two modes, INCLUDE and EXCLUDE INCLUDE allows joining specific sources, SSM –For SSM, sources must be specified EXCLUDE allows blocking specific sources, ASM –Normally for ASM you would block no sources MLDv2 hosts and routers are backwards compatible with MLDv1 –MLDv2 routers and hosts fall back to MLDv1 for a given group if there are MLDv1 reports for the group –Hosts and routers fall back to MLDv1 on an interface (for all groups) if an MLDv1 query is received –The MLDv1 compatibility mode may expire

19. Engineering Workshops 19 MLD on Routers 1/4 To see group memberships we can do: cisco> show ipv6 mld groups MLD Connected Group Membership Group Address Interface Uptime Expires FF1E::1:F00D:BEAC FastEthernet1 3w1d 00:02:58 FF3E::BEAC FastEthernet1 3w1d not used –Note that the last one is an SSM group and we don’t see which sources are joined –Also, there is no expiry, because it’s the individual (S,G)-entries that expire juniper> show mld group Interface: fe-0/0/1.0 Group: ff1e::dead:beef Last Reported by: fe80::2e0:09ff:fe12:34ab Timeout: 213 Type: Dynamic

20. Engineering Workshops 20 MLD on Routers 2/4 To see group memberships including sources we can do: cisco> show ipv6 mld groups detail Interface: FastEthernet1 Group: FF1E::1:F00D:BEAC Uptime: 3w1d Router mode: EXCLUDE (Expires: 00:03:50) Host mode: INCLUDE Last reporter: FE80::211:D8FF:FE8F:1F9B Source list is empty Interface: FastEthernet1 Group: FF3E::BEAC Uptime: 3w1d Router mode: INCLUDE Host mode: INCLUDE Last reporter: FE80::211:D8FF:FE8F:1F9B Group source list: Source Address Uptime Expires Fwd Flags 2001:200:0:8001:250:4FF:FEB7:481D 3w1d 00:03:50 Yes Remote 4 2001:468:900:302:200:5AFF:FE9B:2C64 3w1d 00:03:50 Yes Remote 4 2001:468:901:A:204:76FF:FE3B:2E0B 3w1d 00:03:50 Yes Remote 4 2001:468:914:200::2 3w1d 00:03:50 Yes Remote 4 2001:630:D0:F104:230:48FF:FE2A:CDE 3w1d 00:03:50 Yes Remote 4 2001:630:241:204:211:43FF:FEE1:9FE0 3w1d 00:03:50 Yes Remote 4

21. Engineering Workshops 21 MLD on Routers 3/4 We can also check status for the interfaces or one specific cisco> show ipv6 mld interface fastEthernet 1 FastEthernet1 is up, line protocol is up Internet address is FE80::2E0:F7FF:FE26:9ADA/10 MLD is enabled on interface Current MLD version is 2 MLD query interval is 125 seconds MLD querier timeout is 255 seconds MLD max query response time is 10 seconds Last member query response interval is 1 seconds MLD activity: 70 joins, 56 leaves MLD querying router is FE80::2E0:F7FF:FE26:9ADA (this system) juniper> show mld interface fe-0/0/1 Interface: fe-0/0/1 Querier: fe80::280:42ff:fe12:23de State: Up Timeout: 0 Version: 1 Groups: 1

22. Engineering Workshops 22 MLD on Routers 4/4 In configuration mode there are a number of ipv6 mld commands for changing query intervals and timeout etc, doing static joins, access lists… MLD is enabled by default on interfaces, to disable: cisco(config-if)#no ipv6 mld router protocols { mld { interface fe-0/0/1.0; disable; }

23. Engineering Workshops 23 Multicast and ethernet switches Some switches don’t correctly forward multicast –One problem that has been observed several times, is that hosts can receive multicast for a couple of minutes, and then it stops –The likely reason for this is that the initial unsolicited report from the host reaches the router, but the host is not receiving MLD queries from the router. Try upgrading your switch software if possible In order to restrict the flow of multicast, one may want to use MLD snooping –The first switches supporting MLDv2 are now available –Not aware of MLDv1 snooping switches Due to snooping switches, hosts should also use MLD for link-local groups like the solicited node address –Only exception is the all-nodes address ff02::1 –One drawback is that all IPv6 hosts join solicited node address (and usually unique), so the switch will get a lot of state. Some switches may choose to flood these groups or possibly all link- local multicast

24. Engineering Workshops 24 Lab 1 Multicast on the LAN Time: Approx. ½ hour

25. Engineering Workshops 25 MLD and host state Run ethereal and see what happens when you run ssmping –You should see some MLD packets –Try to look at the content –Check state on host netstat –ngl (on MacOS X, netstat –ain) cat /proc/net/mcfilter6 cat /proc/sys/net/ipv6/mld_max_msf –You can write to mld_max_msf to increase maximum number of source filters Stop ssmping and see what happens

26. Engineering Workshops 26 MLD and router state Run ethereal Enable IPv6 multicast routing on the edge routers (Customer D and Customer E) Do you see any MLD packets? Check the MLD state on the router –Check what groups hosts have joined, including link- locals Check with ethereal what happens when you now run ssmping –You should see some MLD packets –Try to look at the content –Check state on the router, do you see the ssmping source and group?

27. Engineering Workshops 27 Intradomain Multicast

28. Engineering Workshops 28 PIM-SM PIM-SM is the most commonly used multicast routing protocol –There is also IPv6 Bidir PIM for some router software versions In principle PIM is the same for IPv4 and IPv6 A new version of PIM-SM from the IETF –draft-ietf-pim-sm-v2-new, should be finished, but not RFC yet It seems several vendors are using the new spec for IPv6 and the old (RFC 2362) for IPv4 –There are some changes you should be aware of –Link-local addresses are used for PIM messages, including hello’s A new PIM hello option for listing all addresses, see next slide –Tunnel interfaces are used for PIM registers, see later slide

29. Engineering Workshops 29 Basic PIM config on IOS/JUNOS routing-options { rib-groups { mcast-rpf6-rg { import-rib inet6.2; } protocols { pim { rib-group { inet6 mcast-rpf6-rg; } interface all { mode sparse; version 2; } ipv6 multicast-routing

30. Engineering Workshops 30 PIM-SM – Address List Hello Option In many cases one has routes where the next-hop is a global address. In order to find RPF neighbor, the router will then need to know the neighbors global address Since PIM uses link-local addresses for most PIM messages, including hello, an address list hello option was added so a router can learn all addresses of the neighbor’s interface

31. Engineering Workshops 31 Showing PIM Neighbors Showing PIM neighbors cisco> show ipv6 pim neighbor Neighbor Address Interface Uptime Expires DR pri Bidir FE80::260:47FF:FED5:C300 Ethernet1 00:00:16 00:01:28 1 (DR) B FE80::984E:6C02 Tunnel100 17:05:36 00:01:19 1 B juniper> show pim neighbors Instance: PIM.master Interface IP V Mode Option Uptime Neighbor addr ge-2/0/0.0 4 2 HPG 4w3d23h 192.168.2.1 ge-2/1/2.0 4 2 HPLG 4w3d23h 192.124.2.117

32. Engineering Workshops 32 Showing PIM Neighbors Above we got only the link-local addresses. Below we ask to also see that additional addresses from the PIM Hello address list option cisco> show ipv6 pim neighbor detail Neighbor Address(es) Interface Uptime Expires DR pri Bidir FE80::260:47FF:FED5:C300 Ethernet1 00:08:02 00:01:37 1 (DR) B 2001:700:1:1000::1 FE80::984E:6C02 Tunnel100 17:13:22 00:01:28 1 B 2001:630:D0:F000::7:1

33. Engineering Workshops 33 PIM-SM – Register tunnels To simplify the specification, tunnel interfaces are used for encapsulation/decapsulation of PIM register messages E.g. IOS creates and removes tunnel interfaces as needed for RPs There may be some operational issues with that –When an RP goes away (not in RP-set or there is no route for RP address), the interface may go down and be removed –When an RP is added (or returns) a new tunnel is created This does not necessarily re-use previous interface name –It might be hard for management tools etc to distinguish between such interfaces and other interfaces going up and down

34. Engineering Workshops 34 Register tunnels on IOS 1/2 Showing the register interfaces on IOS –encap tunnel interface for each RP address in RP-set –decap tunnel interface for each of our own RP addresses trd-gw4>show ipv6 pim tunnel Tunnel0* Type : PIM Encap RP : 2001:660:3007:300:1:: Source: 2001:700:0:501::4 Tunnel3* Type : PIM Encap RP : 2001:700:0:501::4* Source: 2001:700:0:501::4 Tunnel4* Type : PIM Decap RP : 2001:700:0:501::4* Source: -

35. Engineering Workshops 35 Register tunnels on IOS 2/2 We can also use the normal interface show commands –Packet counters might be useful for debugging trd-gw4> show int tu0 Tunnel0 is up, line protocol is up Hardware is Tunnel … Tunnel source 2001:700:0:501::4 (FastEthernet0/0), destination 2001:660:3007:300:1:: Tunnel protocol/transport PIM/IPv6, key disabled, sequencing disabled … Last input never, output 9w0d, output hang never … 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec … 0 packets input, 0 bytes, 0 no buffer 25722 packets output, 3837176 bytes, 0 underruns

36. Engineering Workshops 36 Register tunnels on JUNOS Juniper uses a hardware Tunnel Services PIC to handle PIM register encapsulation and decapsulation. The interface designation will depend on the slot that the PIC is installed in. juniper> show interface Physical interface: pd-0/3/0, Enabled, Physical link is Up Interface index: 150, SNMP ifIndex: 34 Type: PIMD, Link-level type: PIM-Decapsulator, MTU: Unlimited, Speed: 12800mbps Device flags : Present Running Interface flags: SNMP-Traps Input rate : 0 bps (0 pps) Output rate : 0 bps (0 pps) Logical interface pd-0/3/0.32772 (Index 84) (SNMP ifIndex 0) Flags: Point-To-Point SNMP-Traps 16384 LinkAddress 0-0--- 10020000000000000000000000000000 Encapsulation: PIM-Decap Input packets : 0 Output packets: 0 Protocol inet, MTU: Unlimited Flags: None

37. Engineering Workshops 37 PIM-SM – RP-set configuration Routers can learn their RP-set via static configuration or BSR Routers may also learn RPs from embedded-RP –Router learns the RP when it sees a multicast packet or a join/prune with embedded-RP address –Embedded-RP results in the RP-set being highly dynamic –IOS has started to use one fixed tunnel interface for embedded-RP to reduce amount of tunnel interfaces going up and down

38. Engineering Workshops 38 Embedded-RP tunnels on IOS This router has a permanent embedded-RP tunnel oslo-gw8>show ipv6 pim tunnel Tunnel0* Type : PIM Encap RP : 2001:660:3007:300:1:: Source: 2001:700:0:F000::1 Tunnel5* Type : PIM Encap RP : Embedded RP Tunnel Source: 2001:700:0:F000::1

39. Engineering Workshops 39 RP-set configuration on IOS 1/2 Here we have statically configured one RP –We use acl, else for ff00::/8 –Embedded-RP on by default ipv6 pim rp-address 2001:660:3007:300:1:: rpm6bone ! ipv6 access-list rpm6bone permit ipv6 any FF0E::/16 permit ipv6 any FF1E::/16 permit ipv6 any FF3E::/16 This router has the above config, but is also an embedded-RP ipv6 pim rp-address 2001:660:3007:300:1:: rpm6bone ipv6 pim rp-address 2001:700:0:F000::1 rpemblo1 ! ipv6 access-list rpemblo1 permit ipv6 any FF7E:140:2001:700:0:F000::/96

40. Engineering Workshops 40 RP-set configuration on IOS 2/2 Recommend leaving embedded-RP on, but can be disabled no ipv6 pim rp embedded Some IOS versions support BSR, and is enabled by default. You probably want to block BSR on external interfaces –Although IOS may support scoped BSR where you may have your own internal RPs and learn RPs for only global groups externally interface … ipv6 pim bsr border

41. Engineering Workshops 41 RP-set configuration on JUNOS Again, we have statically configured one RP –Embedded-RP off by default protocols { pim { rp { embedded-rp; static { address 2001:660:3007:300:1:: { group-ranges { ff0e::/16; ff1e::/16; }

42. Engineering Workshops 42 Checking RP-set on IOS To check what RP-set is in use on IOS, use show ipv6 pim range-list or show ipv6 pim group-map This is particularly useful to check that you configured your embedded-RP correctly, or to see what embedded-RPs the router has learned.

43. Engineering Workshops 43 Inspecting router state For most PIM debugging, inspecting the multicast routing state (MRIB) is essential show ipv6 mroute show ipv6 mroute active show ipv6 mroute count We can also check state for specific group or source and group show ipv6 mroute [ ] show ipv6 mroute [ ] count In IOS, there is also a similar command for looking at the forwarding state (MFIB), that takes similar arguments show ipv6 mfib show multicast route group show multicast usage detail show multicast statistics

44. Engineering Workshops 44 RPF As you know, RPF is essential for multicast When things go wrong, it is usually due to incorrect routing and failed or wrong RPF Hence verifying what the RPF interface and neighbor is for an RP address or source address is, is very useful for debugging Below we see an example showing what the RPF is for an address, and what route was used to determine it cisco> show ipv6 rpf 2001:630::dead:beef RPF information for 2001:630::DEAD:BEEF RPF interface: POS2/0 RPF neighbor: FE80::2B0:C2FF:FE83:80 RPF route/mask: 2001:630::/32 RPF type: MBGP RPF recursion count: 1 Metric preference: 10 Metric: 10 juniper> show multicast rpf 2001:468:901::1 Multicast RPF table: inet6.2, 75 entries 2001:468:900::/40 Protocol: BGP Interface: ge-2/0/0.0 Neighbor: 2001:468:ff:1549::2

45. Engineering Workshops 45 Site router configuration In general no configuration apart from RP-set is needed You may want to have a static RP for site scope –Some applications make use of FF05::/16 –E.g. the IANA assigned group FF05::1:3 for all the site’s DHCPv6 servers –Recommend configuring a loopback interface with an address that can be moved around, and static config on all site routers –Might use BSR for this You may want to use embedded-RP –Only need to configure on the RP itself –On e.g. Juniper, embedded-RP must be enabled on each router –Recommend one for global scope if you will create ASM multicast sessions that should be received externally –Might also use with internal scopes Edge routers need to use MLDv2 for SSM, normally default

46. Engineering Workshops 46 ssmping A tool for testing multicast connectivity Behavior is a bit like normal ping A server must run ssmpingd A client can ping a server by sending unicast ssmping query Server replies with both unicast and multicast ssmping replies In this way a client can check that it receives SSM from the server –And also parameters like delay, number of router hops etc. Note that there is also a similar tool called asmping for checking ASM connectivity See http://www.venaas.no/multicast/ssmping/

47. Engineering Workshops 47 How ssmping works ClientServer User runs ssmping Client joins S,G Clients sends unicast to S Server receives unicast ssmping query Responds with ssmping unicast reply and multicast reply to G Client receives replies and prints RTT and hops from server Client sends a new query every second t t

48. Engineering Workshops 48 Example IPv4 ssmping output (v6 supported) -bash-3.00$ ssmping -c 5 -4 ssmping.uninett.no ssmping joined (S,G) = (158.38.62.21,232.43.211.234) pinging S from 129.241.210.1 unicast from 158.38.62.21, seq=0 dist=15 time=72.874 ms unicast from 158.38.62.21, seq=1 dist=15 time=72.663 ms multicast from 158.38.62.21, seq=1 dist=9 time=76.502 ms unicast from 158.38.62.21, seq=2 dist=15 time=72.056 ms multicast from 158.38.62.21, seq=2 dist=9 time=73.556 ms unicast from 158.38.62.21, seq=3 dist=15 time=72.232 ms multicast from 158.38.62.21, seq=3 dist=9 time=73.579 ms unicast from 158.38.62.21, seq=4 dist=15 time=72.513 ms multicast from 158.38.62.21, seq=4 dist=9 time=73.256 ms --- 158.38.62.21 ssmping statistics --- 5 packets transmitted, time 5004 ms unicast: 5 packets received, 0% packet loss rtt min/avg/max/std-dev = 72.056/72.467/72.874/0.415 ms multicast: 4 packets received, 20% packet loss 0% loss since first multicast packet received (after 1077 ms) rtt min/avg/max/std-dev = 73.256/74.223/76.502/1.335 ms -bash-3.00$

49. Engineering Workshops 49 What does the ssmping output tell us? 15 unicast hops from source, only 9 multicast, so tunneling likely Multicast RTTs are larger and varies more –Difference in unicast and multicast RTT shows one way difference for unicast and multicast replies, since they are replies to the same request packet Multicast tree not ready for first multicast reply, ok for 2 nd after 1077ms No unicast loss, no multicast loss after tree established

50. Engineering Workshops 50 Lab 2 Intradomain Multicast Time: Approx. 1 hour

51. Engineering Workshops 51 SSM Look for PIM neighbors and tunnel interfaces on your edge routers Enable multicast routing on the Core-C router Look for PIM neighbors and tunnel interfaces on your core router –Remember to check for non-local neighbor addresses Run ssmping on host Q, pinging host R, leave it running Check PIM state on routers C, D and E –You should see join state, also pay attention to RPF –Try RPF command on R’s address, does output make sense? Start ssmpingd on host R –Does Q receive? Is output correct? Check state on routers, including counts Stop ssmping and see what happens You may also install ssmping on other hosts and test

52. Engineering Workshops 52 ASM We think of the pods as sites, and want to use the site- local scope 5 groups, and need an RP for them. Configure Core-C router as RP for ff05::/16 and ff15::/16 We will test this by running asmping between Q and R asmping is similar to ssmping, but you need to specify group prefix, e.g. asmping ff05:: –Note that asmping sets last 32 bits of group to 4321:1234 Look at router states (e.g. mld and mroute) and also try to understand the asmping output You may also try asmping on other hosts –asmping is part of ssmping package

53. Engineering Workshops 53 Interdomain Multicast

54. Engineering Workshops 54 Interdomain IPv6 multicast For IPv4, each site typical has their own RP for all global groups. RPs in different sites use MSDP to learn of remote sources In this way one avoids relying on a 3 rd party to host some central RP MSDP does not scale, and there is no MSDP for IPv6 The lack of MSDP means that for a given global group there can be only one single RP on the Internet –Hence it is not possible to have scalable services with global well known addresses –E.g. there is SAP (sdr) with group ff0e::2:7ffe, which would require a central common RP for the service, so SAP is not really useful as a global announcement service

55. Engineering Workshops 55 Embedded-RP 1/2 Despite having a single RP per group, there is something we can do With embedded-RP the site hosting some multicast content or session can pick a group using their RP –Everyone on the Internet will then use their RP for that group –There is no 3 rd party responsible Ideally embedded-RPs should be located near the edge A backbone network may not need to do any RP configuration –On some routers embedded-RP must be enabled, but just a simple toggle Embedded-RP on by default on IOS. Needs to be enabled on JunOS Some providers may wish to configure an RP and offer that as a service to customers though. Several customers can use the same RP, but provider should then assign them different group ranges. Since some routers don’t support embedded-RP yet, we have in the M6Bone (incl. Abilene) agreed on one central RP that may be used for ff0e::/16 and ff1e::/16. This does obviously not scale and is expected to be phased out soon.

56. Engineering Workshops 56 Embedded-RP 2/2 One difference from MSDP is that we get shared trees crossing the internet from receiver to the remote RP Since Embedded-RP addresses are based on your unicast addresses, it does not work with IANA-assigned addresses or for application hard-coded groups Users and/or applications need to be configured to use the correct embedded-RP group range. Users should not need to understand embedded-RP. With embedded-RP one should try to use an RP address that never changes –Good idea to use a loopback address that can be moved around as needed

57. Engineering Workshops 57 Router configuration Most routers need minimal configuration As for IPv4 multicast, one may need to run multicast BGP peerings –Usually this is needed where unicast BGP is used and peers wish to exchange multicast Scope boundaries may need to be configured on border routers Edge routers need to use MLDv2 for SSM, may need to be enabled (if not default) For ASM one may need to enable embedded-RP (if not default) –RP routers need to be statically configured –RPs only needed near the edge IOS will by default have IPv6 PIM on all IPv6 interfaces, MLDv2 and embedded-RP JUNOS will need explicit config for PIM, MLD, embedded-RP (and a Tunnel PIC in each router acting as an RP)

58. Engineering Workshops 58 Configuring scope borders on IOS IOS can filter PIM messages on scope borders –If we use scope 8 (and smaller) for our site, we don’t want any join, prunes, registers, BSR messages etc. for scope <= 8 to cross the border –The below filters all but registers (in decimal, e.g. 10, not A) interface … ipv6 multicast boundary scope 8 –Note that the command has changed, old: interface … ipv6 zone boundary 8

59. Engineering Workshops 59 Multicast BGP As for IPv4 multicast, one may need to run multicast BGP peerings for RPF Multiprotocol BGP (MBGP) may have AFI (Address Family Identifier) IPv4/IPv6 and for those, SAFI (Subsequent AFI) –SAFI = 1 for unicast, 2 for multicast, 3 for both –Seems IETF wants to deprecate 3 For a peering one may configure IPv4/IPv6 unicast/multicast separately with different policies Multicast routes used for RPF –Sometimes in addition to unicast routes –One may also sometimes translate unicast routes into multicast Recommend only using multicast BGP –Whenever unicast BGP between multicast networks, enable multicast peering if multicast connectivity is desired –Try to avoid tricks like translation or unicast routes for RPF

60. Engineering Workshops 60 IPv6 Multicast BGP on IOS For multicast RPF, routes from static config and internal routing protocols and also multicast BGP are used –Unicast BGP is usually not used –ipv6 rpf use-bgp enables use of unicast BGP router bgp 224 no bgp default ipv4-unicast neighbor 2001:700:0:F019::2 remote-as 8933 neighbor 2001:700:0:F020::2 remote-as 25689 ! address-family ipv6 unicast ! address-family ipv6 multicast neighbor 2001:700:0:F019::2 activate neighbor 2001:700:0:F019::2 prefix-list emb-rp-tu-prefixes in neighbor 2001:700:0:F019::2 prefix-list le48 out neighbor 2001:700:0:F020::2 activate network 2001:700::/32 exit-address-family

61. Engineering Workshops 61 IPv6 Multicast BGP on JUNOS protocols { bgp { group TRANSIT { type external; family inet6 { any; } neighbor 2001:468:ff12::1 { peer-as 65500; }

62. Engineering Workshops 62 dbeacon dbeacon is a new multicast beacon –http://dbeacon.innerghost.net/ –Alternative to NLANR beacon –IPv4 and IPv6, ASM and SSM –Written in C, light and easy to install –No central server, ASM used for signalling –Any beacon client can be configured to provide a matrix –Beacon options, e.g. dbeacon –b ff7e:a30:2001:db8:10::beac –S –a admin@email –With Apache: ScriptAlias /matrix/ /usr/share/dbeacon-matrix/matrix.pl Edit script for path to matrix $dumpfile = '/var/lib/dbeacon/dump.xml';

63. Engineering Workshops 63 Example dbeacon matrix

64. Engineering Workshops 64 Multicast capable applications Mbone tools, vic/rat etc –IPv6 multicast conferencing applications –http://www-mice.cs.ucl.ac.uk/multimedia/software/ VideoLAN (vlc) –Video streaming, also IPv6 multicast. Server and client –Many operating systems, both Windows and UNIX –http://www.videolan.org/ DVTS http://www.sfc.wide.ad.jp/DVTS/ –Streaming DV over RTP over IPv4/IPv6 –DV devices using Firewire can be connected to two different machines and you can stream video between them over the Internet –Also pure software based playback Mad flute –Streaming of files using multicast (IPv4/IPv6 ASM/SSM) –Linux and Windows (not totally sure about *BSD status) –http://www.atm.tut.fi/mad/

65. Engineering Workshops 65 vic/rat session on M6Bone

66. Engineering Workshops 66 Lab 3 Interdomain Multicast Time: Approx. 2 hours

67. Engineering Workshops 67 Embedded-RP and boundaries Configure Core-C router as embedded-RP for global scope Use asmping to test that it works between hosts in your pod Look at router states, in particular the RP-set while running asmping –Some of your routers should learn the right RP as soon as you start asmping Configure border for scope 5 on external interface of Core-C router, you may also try on border-A router

68. Engineering Workshops 68 External multicast connectivity Enable multicast for your BGP peerings –This should give you external connectivity, both to other pods and outside world Try to asmping some other pod’s host-R using different groups (embedding both your RP and other pod’s RPs) –Try to interpret output and check router states again Set up a beacon client on one of your hosts –We will tell you what parameters to use –You should see which pods can receive which and which can receive from the oustide, check router state again Try to receive some content from the outside, we’ll give you more details

69. Engineering Workshops 69 References Implementing IPv6 multicast –http://www.cisco.com/univercd/cc/td/doc/product/ software/ios123/123cgcr/ipv6_c/sa_mcast.htm